I like the idea of using an env script/bat implementation. It makes lots of
sense in many ways. I don't think one would be allowing users to directly
modify the scripts but we'd ask for their input and validate it before building
the script. So from that perspective the input mechanism is is responsible for
doing the scrubbing.
The bigger issue in my mind is the strategy for supporting multiple server
configurations. A single env script is not adequate for all possible servers
since the user may choose to run different apps on servers that are not part of
the same group.
I'm not sure how WADI is handling this from an admin / config perspective but
they have the same issue in how do we get the right information into a
particular server instance. It sounds like this will most likely be a 2.0
discussion since it will be a significant change over how were currently structured.
One possible (and simple solution) would be to:
$g/var/servers/server1/config.xml
/server2/config.xml
/server3/config.xml
Would contain the meta data used to generate unique env scripts (not very
scalable) or better yet, be used to dynamically build the java command to launch
the desired server.
I guess at some point someone might want to restrict who can configure a set of
servers based on their credentials but I think that's a bit out on the horizon.
To paraphrase Guglielmo, perhaps that is a feature that people will get from
commercial software.
Thoughts?
Matt
Paul McMahan wrote:
I definitely like the idea of adding this type of functionality to the admin
console. A section of setenv.sh/bat could be designated to JVM variables
settable via the admin console. And by surrounding that section with proper
annotation we could probably avoid confusing the user as to what gets set by
whom and when. However, my spidey sense starts tingling when I think about
accepting input from outside the machine (and potentially outside the
firewall) that is placed directly into an script that may be executed with
root/admin privileges. No matter how carefully we sanitize the input some
clever person may figure out some new fangled way to sneak a newline through
or some such mischief. Perhaps there is a way to change (at least some of)
the properties of the JVM *after* it has been executed from the command
line? But now we're back to allowing properties to be set in two places
again, doh! :-)
Best wishes,
Paul
On 1/18/06, John Sisson <[EMAIL PROTECTED]> wrote:
The geronimo.sh/bat startup script will execute a setenv.sh/bat file if
it is present. See the comments at the bottom of the comment header for
geronimo.sh/bat.
For example, the setenv.sh/bat files can set the GERONIMO_OPTS
environment variable to change the JVM options.
We would want to avoid having two places that JVM options are configured
as that would be confusing and make Geronimo more difficult to support.
Maybe the console could have a page that allows you to add/update/delete
environment variables, which results in the appropriate modifications to
the setenv.sh and setenv.bat files. It would need to be careful with
updating/deleting environment variables, as a user may have inserted
some logic in the script before the environment variable is set (or the
environment variable could be in a number of places in the script due to
logic). Maybe the console would need to detect whether the script has
anything other than the simple setting of environment variables and if
so, prevents you from editing it from the console.
It would be interesting to hear from others whether they think it is a
security issue allowing the console to edit bat/sh startup script files
(could malicious commands be inserted into the startup scripts).
John
