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>
Datastage command line
Moderators: chulett, rschirm, roy
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.
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.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
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.
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
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
OK.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
In that case, if -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.
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.
gateleys
OK 'Mr. UNIX Guy'!!!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.
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.
gateleys
Choices are easy (but not nice):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.
- 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.
In theory there's no difference between theory and practice. In practice there is.
Hey ogmios,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.
.
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.
Well, let me decide on that.ogmios wrote: By the way... if you would think DataStage encryption of passwords is secure... think again.
gateleys
Hey ogmios,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.
.
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.
Well, let me decide on that.ogmios wrote: By the way... if you would think DataStage encryption of passwords is secure... think again.
gateleys
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.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.
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).
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++ :DWell, let me decide on that.ogmios wrote: By the way... if you would think DataStage encryption of passwords is secure... think again.
In theory there's no difference between theory and practice. In practice there is.
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.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.
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).
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++ :DWell, let me decide on that.ogmios wrote: By the way... if you would think DataStage encryption of passwords is secure... think again.
In theory there's no difference between theory and practice. In practice there is.
Hi ogmios,
Thanks for your response to the earlier post. Now, with respect to your comment -
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.
Thanks for your response to the earlier post. Now, with respect to your comment -
How will the scheduler password be recognized in the above architecture if I am passing it as an environment variable that is encrypted?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.
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.
gateleys