Discussions
Categories
- 17.9K All Categories
- 3.4K Industry Applications
- 3.3K Intelligent Advisor
- 63 Insurance
- 536.4K On-Premises Infrastructure
- 138.3K Analytics Software
- 38.6K Application Development Software
- 5.8K Cloud Platform
- 109.5K Database Software
- 17.5K Enterprise Manager
- 8.8K Hardware
- 71.1K Infrastructure Software
- 105.3K Integration
- 41.6K Security Software
OMB PLUS - Problem passing Unix environment variables to OMBPlus

666880
Member Posts: 2
Due to a requirement to encapsulate deployment of OWB applications, we currently start OMBPlus.sh from our own wrapper ksh script (deploy.ksh) in order to get the new / changed application into the target control center etc.
We now have a new requirement that means we need to pass the content of the Unix environment across to OMBPlus.sh (and from thence into our deployment tcl scripts).
No problem, if you believe the tcl documentation. The entire Unix environement gets dumped into a hash array called 'env', so you can get the variable's value out just by saying $env(unix_valraible).
Sounds great, it should work a treat.
Except OMBPlus only silghtly resembles tclsh.
The 'env' that gets into OMBPlus bears practically no resemblance to the 'env' that existed before OMBPlus.sh got invoked.
Does anyone have:
a decent explanation for why the env gets scrambled (and how to avoid it) ?
or an alternative method of getting the Unix environment varaible values into OMBPlus ?
Please do not propose passing them all on the command line because (would you beleive it) the values are database passwords !
Edited by: user10466244 on 23.10.2008 09:28
We now have a new requirement that means we need to pass the content of the Unix environment across to OMBPlus.sh (and from thence into our deployment tcl scripts).
No problem, if you believe the tcl documentation. The entire Unix environement gets dumped into a hash array called 'env', so you can get the variable's value out just by saying $env(unix_valraible).
Sounds great, it should work a treat.
Except OMBPlus only silghtly resembles tclsh.
The 'env' that gets into OMBPlus bears practically no resemblance to the 'env' that existed before OMBPlus.sh got invoked.
Does anyone have:
a decent explanation for why the env gets scrambled (and how to avoid it) ?
or an alternative method of getting the Unix environment varaible values into OMBPlus ?
Please do not propose passing them all on the command line because (would you beleive it) the values are database passwords !
Edited by: user10466244 on 23.10.2008 09:28
Answers
-
Unfortunately, the java implementation of TCL that Oracle used as the basis for OMB+ is NOT a fully-featured implementation. Just try using packages...
However, and understanding why you don't want to hard-code passwords into a file, you can always edit the setowbenv.sh file in your owb/bin/unix directory to grab your specific shell environment variables and propogate them to the java session.
towards the bottom of this env file you will see a section that looks something like:
JDK_HOME=../../../jdk
OWB_HOME=/owb
ORA_HOME=/owb
OEM_HOME=/owb
IAS_HOME=/owb
ORACLE_HOME=/owb
CLASSPATH=Personalties.jar:../admin:$MIMB_JAR:
CLASSPATH_LAUNCHER="-classpath ../admin:../admin/launcher.jar:$CLASSPATH: -DOWB_HOME=$OWB_HOME -DJDK_HOME=$JDK_HOME -DORA_HOME=$ORA_HOME -DOEM_HOME=$OEM_HOME -DIAS_HOME=$IAS_HOME -Doracle.net.tns_admin=$ORA_HOME/network/admin Launcher ../admin/owb.classpath"
export ORA_HOME
export OWB_HOME
export JDK_HOME
export OEM_HOME
export IAS_HOME
export ORACLE_HOME
You could add in the environment variables that you want propogated, include them into the CLASSPATH_LAUNCHER, and then they will turn up in your OMB+ session env array.
e.g., to propgate an environment variable called MY_DATABASE_PASSWORD you would:
JDK_HOME=../../../jdk
OWB_HOME=/owb
ORA_HOME=/owb
OEM_HOME=/owb
IAS_HOME=/owb
ORACLE_HOME=/owb
CLASSPATH=Personalties.jar:../admin:$MIMB_JAR:
CLASSPATH_LAUNCHER="-classpath ../admin:../admin/launcher.jar:$CLASSPATH: -DOWB_HOME=$OWB_HOME -DMY_DATABASE_PASSWORD=${MY_DATABASE_PASSWORD} -DJDK_HOME=$JDK_HOME -DORA_HOME=$ORA_HOME -DOEM_HOME=$OEM_HOME -DIAS_HOME=$IAS_HOME -Doracle.net.tns_admin=$ORA_HOME/network/admin Launcher ../admin/owb.classpath"
export ORA_HOME
export OWB_HOME
export JDK_HOME
export OEM_HOME
export IAS_HOME
export ORACLE_HOME
So now you have no protected data hardcoded, it will pick up your specific environment variables at runtime, and when you start OMB+ you will be able to:
array get env MY_DATABASE_PASSWORD.
cheers,
Mike -
Thanks for the hint 'zeppo',
actually I had already looked into that, but as I am not the 'DBA', I really cannot go changing bits of OMBPlus.
Still, if this is the only way, then I can maybe threaten to send the boys round !
Of course, I would want to make it a bit more generic. The same setowbenv.sh gets used everytime OMBPlus.sh is called, but these variables are 'variable' (not only their values change), also their 'names' change depending on the context of the shell script that is calling OMBPlus.sh and the OMB/tcl script that we are trying to run.
Anyway, thanks again, and I will ost any progress I make this end. -
Oh, I agree that editing an Oracle file is far from optimal, however the java session that runs OMB+ will only ever have those environment variables. Mind you, you could build your list dynamically such as:
in setowbenv.sh, just before the CLASSPATHLAUNCHER definition do something like:
MY_SHELL_VARS=`env | grep PASS | sed s/^/-D/ | awk '{printf $0; printf " "}'`
This will generate a list of -D java variables or all unix environment variables with PASS in them, then just insert that into the CLASSPATHLAUNCHER defintion (edit the grep or not as needed)
CLASSPATH_LAUNCHER="-classpath ../admin:../admin/launcher.jar:$CLASSPATH: -DOWB_HOME=$OWB_HOME -DJDK_HOME=$JDK_HOME -DORA_HOME=$ORA_HOME -DOEM_HOME=$OEM_HOME -DIAS_HOME=$IAS_HOME $MY_SHELL_VARS -Doracle.net.tns_admin=$ORA_HOME/network/admin Launcher ../admin/owb.classpath"
O sheesh - am I overcomplicating....? have you tried using exec? The unix commands that it will run is often a pain due to file permissions issues, but does the following properly grab what you need?OMB+> set x [exec env] OMB+> foreach y $x { OMB+> puts "ENVIRONMENT VARIABLE: $y" OMB+> }
I'm away from my work machine right now, so I can't test what 'exec env' will generate. let me know. -
What a great thread! So, has anyone gone the rest of the way in the last year and gotten this to actually convert a Unix env var to an OMBPlus one? Seems like this last bit (tks to Zeppo) get us almost all the way there - just need to add something to parse out the results of the "env" call and iterate through that instantiating UNIX vars to vars. And then, better yet, add the ability to do it selectively, so it will only do a single named var, etc...
Or, is there another way?
Forum search doesn't seem to show anyone else doing this yet so I'll happily go take a crack at it if no one else has...
Cheers,
Jim C. -
OK - so here's a first pass at a working solution:
proc hostvar { varname } {
foreach y [exec env] {
set evname [lindex [split $y =] 0]
set evvalue [lindex [split $y =] 1]
if { $evname == $varname } {
# global $evname
# set $evname $evvalue
return $evvalue
}
}
}
Then you can just use
set a [hostvar ORACLE_SID]
to get the value of the env. var "ORACLE_SID" into the tcl/OMB variable "a".
The only slightly ugly part of this is that the "return" seems to be echoing the results (the env var value) back out to the screen - some way to stop that? Not a show-stopper for me but might be nice to clean up...
Note: I'd also played with the two commented out lines to instantiat e a tcl variable with the same name/value as the host env var, so if you'd rather, you can do it that way too. Just uncommenting those 2 lines (and removing the "return" line) would allow:
hostvar ORACLE_SID
to then populate a tcl var with the same name/value.
May well be easier ways to do this, but this seems to be working for me.
Cheers,
Jim C. -
Sorry - slight typo addition (or Forum software, or browser maybe, seems to converting the brackets...)
"set" usage should include square brackets around the "hostvar <varname>" call to execute hostvar proc, as in:
set a [hostvar ORACLE_SID]
(Ignore the underlined "link" that the forum software is displaying)
Cheers,
Jim C.
Edited by: Jim2 on Sep 12, 2009 1:37 PM -
lmao - I saw this thread title and thought "Hey, that looks interesting!" completely forgetting that I had been invloved with it last year!
Jim, to get the forum to leave your code alone, you want to format it as code. The tags to put around your code is
open-curly-brace code close-curly brace
insert
your
formatted code
right
here
open-curly-brace code close-curly brace
(and yes the opening and closing tags are the same.
which generated:insert your formatted code right here
Glad to see that someone ran with this and made it work!
Mike -
Ahh - thanks, Mike - that was the magic I couldn't find in the "Help" page on the editor window! So, here's the code snippet again then, just to be clear:
proc hostvar { varname } { foreach y [exec env] { set evname [lindex [split $y =] 0] set evvalue [lindex [split $y =] 1] if { $evname == $varname } { # global $evname # set $evname $evvalue return $evvalue } } } # # Example call to set an OWB variable called BUILD_HOME with the value of the Unix env var of the same name... # set BUILD_HOME [hostvar BUILD_HOME]
Cheers,
Jim C.
This discussion has been closed.