DSXchange

Looking for some examples on how to set up a dsjob command line. I have the following command line but would like to find out a way to hide the userid and password information.

dsjob -server <server> -user <username> -password <password> -run <project> <job>

Welcome! :D

The only way to 'hide' that I am aware of is to use the "-file" option. However, some people find this unacceptable as it requires the server,userid & password information to be read from a plain text file on the DataStage server.

Thanks, would have an example of how this would be coded? I moved the -server -user and -password to a file and specified

dsjob -file LOGIN.TXT -run <project> <job>

but it's failing to locate the server.

Did you check the docs so you have the format of the file correct? I don't have it handy, but it is documented and something like this off the top of my head:

server,userid,password

And you still have to specify the -server on the command line so it knows which record in the file to use as it supports more than one. This just allows you to leave off the userid and password.

Craig is right.

you have to use -server in the command.
dsjob -file <filename> <servername> ------

and the <filename> should contain:
servername,userid,password

kris wrote:Craig is right.

you have to use -server in the command.
dsjob -file <filename> <servername> ------

and the <filename> should contain:
servername,userid,password

OK.

chulett wrote: However, some people find this unacceptable as it requires the server,userid & password information to be read from a plain text file on the DataStage server.

In that case, if -
1. the server is running on Windows
2. and the above dsjob command is written in a .BAT file with at least the userid and password as batch file parameters
3. and we want to pass values to these parameters from the environment variable set in DS Admin client (and not from the file .... so that these sensitive information are not stored in some plain text in a file).

How would the above be achieved?

I am just adding further value to the question ... not hijacking it.

Craig??

Yes?

Keep in mind the fact that I have zero 'DataStage on Windows' experience, having spent my entire life happily camped out in UNIX Land. Which is why I left this for others to (hopefully) answer.

And ps: this is a classic hijack.

chulett wrote:Yes?

Keep in mind the fact that I have zero 'DataStage on Windows' experience, having spent my entire life happily camped out in UNIX Land. Which is why I left this for others to (hopefully) answer.

And ps: this is a classic hijack.

OK 'Mr. UNIX Guy'!!!

How, then, would you do it if -
1. the server is running on UNIX
2. and the above dsjob command is embedded in a ksh script with at least the userid and password as parameters
3. and we want to pass values to these parameters from the environment variable set in DS Admin client (and not from the file .... so that these sensitive information are not stored in some plain text in a file).

And I still insist that it is not a hijack, but taking the OP's question further to instil clarity and completeness.

OK 'Mr. UNIX Guy'!!!

How, then, would you do it if -
1. the server is running on UNIX
2. and the above dsjob command is embedded in a ksh script with at least the userid and password as parameters
3. and we want to pass values to these parameters from the environment variable set in DS Admin client (and not from the file .... so that these sensitive information are not stored in some plain text in a file).

And I still insist that it is not a hijack, but taking the OP's question further to instil clarity and completeness.

Choices are easy (but not nice):
- either you use id/passwords in the dsjob command line and people will be able to see them if the do ps -efl
- either you write the passwords in a (in your case temp) file, properly chmodded and used that as input to dsjob -file ... and erase the temp file afterwards.

By the way... if you would think DataStage encryption of passwords is secure... think again.

ogmios wrote: Choices are easy (but not nice):
- either you use id/passwords in the dsjob command line and people will be able to see them if the do ps -efl
- either you write the passwords in a (in your case temp) file, properly chmodded and used that as input to dsjob -file ... and erase the temp file afterwards.
.

Hey ogmios,

1. My earlier posts here are aimed at securing the 'scheduler' password. Hence, the straightforward solution (your first) is out of the question.

2. If you look at my first post to this thread, you will see that I have already agreed to the solution of using the -file argument for dsjob. The problem, I repeat, is that the passwords are stored in plaintext in the file. I would, rather, that the environment variables are passed as arguments to the dsjob command. And that is the whole point of my post/argument.

ogmios wrote: By the way... if you would think DataStage encryption of passwords is secure... think again.

Well, let me decide on that.

ogmios wrote: Choices are easy (but not nice):
- either you use id/passwords in the dsjob command line and people will be able to see them if the do ps -efl
- either you write the passwords in a (in your case temp) file, properly chmodded and used that as input to dsjob -file ... and erase the temp file afterwards.
.

Hey ogmios,

1. My earlier posts here are aimed at securing the 'scheduler' password. Hence, the straightforward solution (your first) is out of the question.

2. If you look at my first post to this thread, you will see that I have already agreed to the solution of using the -file argument for dsjob. The problem, I repeat, is that the passwords are stored in plaintext in the file. I would, rather, that the environment variables are passed as arguments to the dsjob command. And that is the whole point of my post/argument.

ogmios wrote: By the way... if you would think DataStage encryption of passwords is secure... think again.

Well, let me decide on that.

2. If you look at my first post to this thread, you will see that I have already agreed to the solution of using the -file argument for dsjob. The problem, I repeat, is that the passwords are stored in plaintext in the file. I would, rather, that the environment variables are passed as arguments to the dsjob command. And that is the whole point of my post/argument.

Pass the environment variables, write those to a temp file (chmod 700 e.g.), run dsjob -file, erase temp file. Securest way we found with the current functionality.

Encryption or not/variables or not is actually all pretty moot. You just have to secure the scheduler account and make sure no-one logs the encrypted passwords to the logs. Once you have access to the scheduler account you are able to get the passwords back (even when they would be encrypted, as DataStage would also need to decrypt them).

ogmios wrote: By the way... if you would think DataStage encryption of passwords is secure... think again.

Well, let me decide on that.

You can decipher the algorithm in 15 minutes. I'll give you a hint, every character in the original is translated into 3 characters, and the position of a character in the original string is used in shifting through 3 lookup tables ... kind of a ROT13++ :D

2. If you look at my first post to this thread, you will see that I have already agreed to the solution of using the -file argument for dsjob. The problem, I repeat, is that the passwords are stored in plaintext in the file. I would, rather, that the environment variables are passed as arguments to the dsjob command. And that is the whole point of my post/argument.

Pass the environment variables, write those to a temp file (chmod 700 e.g.), run dsjob -file, erase temp file. Securest way we found with the current functionality.

Encryption or not/variables or not is actually all pretty moot. You just have to secure the scheduler account and make sure no-one logs the encrypted passwords to the logs. Once you have access to the scheduler account you are able to get the passwords back (even when they would be encrypted, as DataStage would also need to decrypt them).

ogmios wrote: By the way... if you would think DataStage encryption of passwords is secure... think again.

Well, let me decide on that.

You can decipher the algorithm in 15 minutes. I'll give you a hint, every character in the original is translated into 3 characters, and the position of a character in the original string is used in shifting through 3 lookup tables ... kind of a ROT13++ :D

Hi ogmios,
Thanks for your response to the earlier post. Now, with respect to your comment -

ogmios wrote: Pass the environment variables, write those to a temp file (chmod 700 e.g.), run dsjob -file, erase temp file. Securest way we found with the current functionality.

How will the scheduler password be recognized in the above architecture if I am passing it as an environment variable that is encrypted?

I mean, the process will write an encrypted password to the temp file. So, when the dsjob command lifts the password from the file, it will be encrypted.

This would be similar to typing the encrypted version of the password directly on any database stage password field, and expect it to work, isn't it?

Would appreciate your comment on this ogmios. Or anybody.