database password changed
Moderators: chulett, rschirm, roy
database password changed
Hi friends,
all of suddenly my manager changed the PASSWORD for database.
so what are options now?
open up each and every job change the password and compile is the only option??
thanks for ur help in advance
all of suddenly my manager changed the PASSWORD for database.
so what are options now?
open up each and every job change the password and compile is the only option??
thanks for ur help in advance
No, your developer should have used parameters instead of hardcoded values. If your developer used parameters, and simply hardcoded defaults, then you can use any of the mass parameter update utilities available. Search for Parameter Manager offered on this sites companion tools section. If your developer plugged literal credential values into the fields instead of parameters, then you need to have a strong talk with them about their quality of work. And then open every job and not just change the value but replace it with parameters so that this never happens again. You should have parameter values fed to your jobs at startup and not embed them in the code, even as defaults to parameters.
I would never allow developers to write a shell script and embed passwords and directory paths. Why should DataStage jobs be allowed to have the same done to them?
I would never allow developers to write a shell script and embed passwords and directory paths. Why should DataStage jobs be allowed to have the same done to them?
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Never use absolute pathing....
All the responses have said enough. Never use absolute pathing but rather relative pathing by using .ini, .par or .config files.
And, of course and as mentioned by trokosz, the discussion ranges well beyond just database passwords. The Rule of Thumb should be that anything that can change from environment to environment, day to day, release to release should be parameterized.
For databases that can be DSN, Host, Userid, Password and even Owner. Flat files, location and file name. The list goes on and on.
After that, a job control architecture that lets you store your parameter values in a central location, so that when something changes its a simple matter of editing it in one place rather than (possibly) several hundred is ideal.
For databases that can be DSN, Host, Userid, Password and even Owner. Flat files, location and file name. The list goes on and on.
After that, a job control architecture that lets you store your parameter values in a central location, so that when something changes its a simple matter of editing it in one place rather than (possibly) several hundred is ideal.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
Only if you use the dsjob program to set parameters and run jobs. If you build your own job control using a Batch job, Sequencer, or custom job control, you have the ability to fetch parameter values and directly control the setting and running of jobs.leomauer wrote:This is all nice and dandy. I love parameters. But the password is a different animal. It is a security issue. If hard codded in the job then it is masked. Yet passed as a perameter value it is open to everybody who can ps -ef the processes.
Any ideas?
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
We are using dsjob program.kcbland wrote: Only if you use the dsjob program to set parameters and run jobs. If you build your own job control using a Batch job, Sequencer, or custom job control, you have the ability to fetch parameter values and directly control the setting and running of jobs.
How to do that?Sainath.Srinivasan wrote: Password must be an 'Encrypted' value and hence during execution or resulting log will represent only a cryptic representation.
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
Thanks.Sainath.Srinivasan wrote:You can have a master control job that reads from an ini file for the values and attaches to a job (name being a parameter to the master) and set the parameters as found necessary in the job.
But I am working with UNIX server. I can read a protected file but when I pass the password value to dsjob this value becomes visible using ps -ef. I am interested about your suggested "Encrypted" values from the responce before.
So then don't pass any userid/password to dsjob: launch a job via dsjob and have that job read a protected file somewhere and pass the password to other DataStage jobs. You will find several routines on this site to do such stuff.But I am working with UNIX server. I can read a protected file but when I pass the password value to dsjob this value becomes visible using ps -ef. I am interested about your suggested "Encrypted" values from the responce before.
This does mean that if the job you currently execute is a GUI job and not a BASIC job, you will have write an extra DataStage BASIC job (or a sequencer) to fetch the parameters and startup other jobs (in your case this would probably mean moving UNIX script functionality to DataStage BASIC).
About encryption, as I wrote before DataStage encryption (the kind of type you can set for passwords in the parameter dialog) is easily breakable for people who know even a little bit of math.
Ogmios
In theory there's no difference between theory and practice. In practice there is.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom