When you talk about a headless server... Is it acceptable to have
a GUI tool that you run remotely via X-over-ssh, or does the server have
no X install such that even that wouldn't work?
In any case, I think your writeup is sensible. However, it may be
difficult to implement the upgrade compatiblity where a new install
detects and defaults to the settings in an old install. I'd call this a
"nice to have", but in any case it doesn't have to be ready until our
second release (so you have something to upgrade from)... :)
Aaron
On Mon, 20 Jun 2005 [EMAIL PROTECTED] wrote:
> The following are my thoughts regarding requirements for
> running/configuring geronimo on a headless server in a production
> environment..
>
> Whatever solution we come up with for changing the configuration settings
> (e.g. port numbers) it needs to be 'usable' in a headless environment. By
> that I mean that it should be 'easy' to change the configuration settings
> on a headless machine, e.g. not having to regenerate the configuration
> from scratch via a GUI on another machine and transfer the configuration
> over manually (e.g. ftp) etc. The solution could be a command line
> interface, or it could be a GUI solution that allows one to run a
> configuration server component on a specified port (consider that more
> than one instance of geronimo could be running on the server and each
> instance could be running at a different version) and connect to it from a
> client machine (with minimal steps required by the user).
>
> We should allow GBean attributes to be changed whilst geronimo isn't
> running without requiring the configuration be rebuilt from scratch
> because whilst geronimo is in production, people may have tinkered with
> Gbean attribute values (e.g. via a JMX console) e.g. to tune it, but those
> people may have forgotten to make the same changes to the files (XML
> plans) that are used to generate configurations the next time around. The
> only time I think it should be necessary to rebuild a configuration from
> scratch is when you are installing a new version of geronimo. When a
> configuration is built for a new release, the user shouldn't have to
> re-enter all the settings in the GUI again (this would be prone to user
> error), they should be able to import the existing configuration into the
> configuration tool, with a validation step identifying screens/fields
> where new mandatory fields need to be entered in the configuration.
>
> Consider the following scenario.. Geronimo has been running for months in
> a production environment, where months ago, GBeans attribute values that
> configured the locations of files (e.g. transaction logs and database
> files) were changed from the default location to point to a different
> disk. At present, Geronimo has been shut down during a hardware
> maintenance window where a newer high speed disk has been installed. The
> operations staff now want to change the configuration of the file
> locations in some GBean attributes to point to that new disk (they have
> moved the files), without touching any other Gbean attribute values that
> may have been previously customised (months ago) to minimise risk.
>
> Comments?
>
> John
>
> This e-mail message and any attachments may contain confidential,
> proprietary or non-public information. This information is intended
> solely for the designated recipient(s). If an addressing or transmission
> error has misdirected this e-mail, please notify the sender immediately
> and destroy this e-mail. Any review, dissemination, use or reliance upon
> this information by unintended recipients is prohibited. Any opinions
> expressed in this e-mail are those of the author personally.
