You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2007/08/28 16:41:24 UTC
Too easy to kill the server using the web console
GERONIMO-3401 ( https://issues.apache.org/jira/browse/GERONIMO-3401 )
records a problem where it is possible for the user to cripple the web
console, the server or both with 1 or 2 mouse clicks.
When stopping some system-modules such as the following from the web
console, the web console itself is also stopped due to direct and
transitive dependencies:
- activemq-broker
- connector-deployer
- geronimo-gbean-deployer
- j2ee-corba-yoko
- j2ee-deployer
- j2ee-security
- j2ee-server
- j2ee-system
- jasper
- jee-specs
- openejb
- openjpa
- rmi-naming
- server-security-config
- tomcat6
- tomcat6-deployer
- jetty6
- jetty6-deployer
- transaction
- webservices-common
- xmlbeans
The result is an error in the browser, and exception in the server, and
the web console disabled. One cheap way to help prevent this problem is
to add a challenge when any system module is stopped to ensure the user
is aware that stopping a system module might result in rendering the web
console unusable. The situation can be recovered via the CLI by
subsequently starting the web console but this might not be obvious to
the user and often a server restart is necessary before the CLI itself
can function again.
However, there is another problem that is much more serious. If the
user selects "uninstall" on any of the modules listed above, in addition
to the web console being disabled, the server itself is corrupted. In
fact, in most cases the server cannot start once it is shutdown. AFAIK,
there is no easy recovery from this. There is a challenge already
provided to he user when uninstall is selected but it doesn't hint at
the potential severity of the consequences.
I'm thinking we should remove the uninstall capability from the system
module view in the web console until we have more pluggable components
that can be installed/uninstalled without crippling the entire server. A
challenge (even if worded more strongly) just doesn't seem sufficient.
Of course we have this same exposure with the CLI but it isn't quite as
easy to shoot yourself in the foot there with just 2 mouse clicks.
Thoughts?
Joe
Re: Too easy to kill the server using the web console
Posted by Joe Bohn <jo...@earthlink.net>.
David Jencks wrote:
> I don't like prohibiting people from doing stuff because we think we
> know better. I think there are valid reasons to stop and uninstall most
> of these modules, although you may need to be an expert to be able to
> start the server afterwards.
Yes, I see your point ... and it does get tricky trying to decide when
to permit an action and when to prevent it.
>
> How about if for both stop and uninstall we show a list of the modules
> that will be stopped or rendered inoperable as a result? This would be
> the transitive closure of the "child" view in the modules pages.
We already show the immediate children (as you point out) and I think
the user kind of glazes over at that list. The transitive list would be
even larger and possibly more likely to be ignored. Still ... it's
worth exploring.
For a quick fix for now I think I will just go with a sternly worded
challenge if the module to be stopped/uninstalled is a SERVICE or starts
with org.apache.geronimo.*
Thanks,
Joe
>
> thanks
> david jencks
>
> On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote:
>
>> GERONIMO-3401 ( https://issues.apache.org/jira/browse/GERONIMO-3401 )
>> records a problem where it is possible for the user to cripple the web
>> console, the server or both with 1 or 2 mouse clicks.
>>
>> When stopping some system-modules such as the following from the web
>> console, the web console itself is also stopped due to direct and
>> transitive dependencies:
>> - activemq-broker
>> - connector-deployer
>> - geronimo-gbean-deployer
>> - j2ee-corba-yoko
>> - j2ee-deployer
>> - j2ee-security
>> - j2ee-server
>> - j2ee-system
>> - jasper
>> - jee-specs
>> - openejb
>> - openjpa
>> - rmi-naming
>> - server-security-config
>> - tomcat6
>> - tomcat6-deployer
>> - jetty6
>> - jetty6-deployer
>> - transaction
>> - webservices-common
>> - xmlbeans
>>
>>
>> The result is an error in the browser, and exception in the server,
>> and the web console disabled. One cheap way to help prevent this
>> problem is to add a challenge when any system module is stopped to
>> ensure the user is aware that stopping a system module might result in
>> rendering the web console unusable. The situation can be recovered
>> via the CLI by subsequently starting the web console but this might
>> not be obvious to the user and often a server restart is necessary
>> before the CLI itself can function again.
>>
>> However, there is another problem that is much more serious. If the
>> user selects "uninstall" on any of the modules listed above, in
>> addition to the web console being disabled, the server itself is
>> corrupted. In fact, in most cases the server cannot start once it is
>> shutdown. AFAIK, there is no easy recovery from this. There is a
>> challenge already provided to he user when uninstall is selected but
>> it doesn't hint at the potential severity of the consequences.
>>
>> I'm thinking we should remove the uninstall capability from the system
>> module view in the web console until we have more pluggable components
>> that can be installed/uninstalled without crippling the entire server.
>> A challenge (even if worded more strongly) just doesn't seem
>> sufficient. Of course we have this same exposure with the CLI but it
>> isn't quite as easy to shoot yourself in the foot there with just 2
>> mouse clicks. Thoughts?
>>
>> Joe
>>
>
>
Re: Too easy to kill the server using the web console
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I like that idea. Keep people safe but let them blaze on if they so
desire.
On Aug 28, 2007, at 12:02 PM, Aaron Mulder wrote:
> I guess we could also disable stop and undeploy for the system modules
> and have an "expert mode" checkbox or something on the screen to
> enable them again. That ought to be clue enough. :)
>
Re: Too easy to kill the server using the web console
Posted by Joe Bohn <jo...@earthlink.net>.
Both good suggestions.
Thanks!
Joe
Aaron Mulder wrote:
> I guess we could also disable stop and undeploy for the system modules
> and have an "expert mode" checkbox or something on the screen to
> enable them again. That ought to be clue enough. :)
>
> Thanks,
> Aaron
>
> On 8/28/07, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>> It probably would still be good to have some text like "WARNING: only
>> expert users will be able to restart the server after this is done."
>> Just seeing a list of components to be stopped won't necessarily clue
>> in "the average user" to the potential impact... But of course we'd
>> only want to display that if it was really the case, so perhaps we can
>> just detect whether the really important startup-fails-without-this
>> modules are in the dependency list.
>>
>> Thanks,
>> Aaron
>>
>> On 8/28/07, David Jencks <da...@yahoo.com> wrote:
>>> I don't like prohibiting people from doing stuff because we think we
>>> know better. I think there are valid reasons to stop and uninstall
>>> most of these modules, although you may need to be an expert to be
>>> able to start the server afterwards.
>>>
>>> How about if for both stop and uninstall we show a list of the
>>> modules that will be stopped or rendered inoperable as a result?
>>> This would be the transitive closure of the "child" view in the
>>> modules pages.
>>>
>>> thanks
>>> david jencks
>>>
>>> On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote:
>>>
>>>> GERONIMO-3401 ( https://issues.apache.org/jira/browse/
>>>> GERONIMO-3401 ) records a problem where it is possible for the user
>>>> to cripple the web console, the server or both with 1 or 2 mouse
>>>> clicks.
>>>>
>>>> When stopping some system-modules such as the following from the
>>>> web console, the web console itself is also stopped due to direct
>>>> and transitive dependencies:
>>>> - activemq-broker
>>>> - connector-deployer
>>>> - geronimo-gbean-deployer
>>>> - j2ee-corba-yoko
>>>> - j2ee-deployer
>>>> - j2ee-security
>>>> - j2ee-server
>>>> - j2ee-system
>>>> - jasper
>>>> - jee-specs
>>>> - openejb
>>>> - openjpa
>>>> - rmi-naming
>>>> - server-security-config
>>>> - tomcat6
>>>> - tomcat6-deployer
>>>> - jetty6
>>>> - jetty6-deployer
>>>> - transaction
>>>> - webservices-common
>>>> - xmlbeans
>>>>
>>>>
>>>> The result is an error in the browser, and exception in the server,
>>>> and the web console disabled. One cheap way to help prevent this
>>>> problem is to add a challenge when any system module is stopped to
>>>> ensure the user is aware that stopping a system module might result
>>>> in rendering the web console unusable. The situation can be
>>>> recovered via the CLI by subsequently starting the web console but
>>>> this might not be obvious to the user and often a server restart is
>>>> necessary before the CLI itself can function again.
>>>>
>>>> However, there is another problem that is much more serious. If
>>>> the user selects "uninstall" on any of the modules listed above, in
>>>> addition to the web console being disabled, the server itself is
>>>> corrupted. In fact, in most cases the server cannot start once it
>>>> is shutdown. AFAIK, there is no easy recovery from this. There is
>>>> a challenge already provided to he user when uninstall is selected
>>>> but it doesn't hint at the potential severity of the consequences.
>>>>
>>>> I'm thinking we should remove the uninstall capability from the
>>>> system module view in the web console until we have more pluggable
>>>> components that can be installed/uninstalled without crippling the
>>>> entire server. A challenge (even if worded more strongly) just
>>>> doesn't seem sufficient. Of course we have this same exposure with
>>>> the CLI but it isn't quite as easy to shoot yourself in the foot
>>>> there with just 2 mouse clicks. Thoughts?
>>>>
>>>> Joe
>>>>
>>>
>>>
>
Re: Too easy to kill the server using the web console
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
Or simulate some burning smell by maxing on the CPU and burning some
hardware if possible :o)
On 8/29/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
> One other thought...perhaps we could play an audio clip of a shotgun or
> other firearm action being moved to suggest the consequences of hitting
> enter :)
>
> On Aug 28, 2007, at 12:02 PM, Aaron Mulder wrote:
>
> I guess we could also disable stop and undeploy for the system modules
>
> and have an "expert mode" checkbox or something on the screen to
>
> enable them again. That ought to be clue enough. :)
>
>
>
>
Re: Too easy to kill the server using the web console
Posted by Matt Hogstrom <ma...@hogstrom.org>.
One other thought...perhaps we could play an audio clip of a shotgun
or other firearm action being moved to suggest the consequences of
hitting enter :)
On Aug 28, 2007, at 12:02 PM, Aaron Mulder wrote:
> I guess we could also disable stop and undeploy for the system modules
> and have an "expert mode" checkbox or something on the screen to
> enable them again. That ought to be clue enough. :)
>
Re: Too easy to kill the server using the web console
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I guess we could also disable stop and undeploy for the system modules
and have an "expert mode" checkbox or something on the screen to
enable them again. That ought to be clue enough. :)
Thanks,
Aaron
On 8/28/07, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> It probably would still be good to have some text like "WARNING: only
> expert users will be able to restart the server after this is done."
> Just seeing a list of components to be stopped won't necessarily clue
> in "the average user" to the potential impact... But of course we'd
> only want to display that if it was really the case, so perhaps we can
> just detect whether the really important startup-fails-without-this
> modules are in the dependency list.
>
> Thanks,
> Aaron
>
> On 8/28/07, David Jencks <da...@yahoo.com> wrote:
> > I don't like prohibiting people from doing stuff because we think we
> > know better. I think there are valid reasons to stop and uninstall
> > most of these modules, although you may need to be an expert to be
> > able to start the server afterwards.
> >
> > How about if for both stop and uninstall we show a list of the
> > modules that will be stopped or rendered inoperable as a result?
> > This would be the transitive closure of the "child" view in the
> > modules pages.
> >
> > thanks
> > david jencks
> >
> > On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote:
> >
> > > GERONIMO-3401 ( https://issues.apache.org/jira/browse/
> > > GERONIMO-3401 ) records a problem where it is possible for the user
> > > to cripple the web console, the server or both with 1 or 2 mouse
> > > clicks.
> > >
> > > When stopping some system-modules such as the following from the
> > > web console, the web console itself is also stopped due to direct
> > > and transitive dependencies:
> > > - activemq-broker
> > > - connector-deployer
> > > - geronimo-gbean-deployer
> > > - j2ee-corba-yoko
> > > - j2ee-deployer
> > > - j2ee-security
> > > - j2ee-server
> > > - j2ee-system
> > > - jasper
> > > - jee-specs
> > > - openejb
> > > - openjpa
> > > - rmi-naming
> > > - server-security-config
> > > - tomcat6
> > > - tomcat6-deployer
> > > - jetty6
> > > - jetty6-deployer
> > > - transaction
> > > - webservices-common
> > > - xmlbeans
> > >
> > >
> > > The result is an error in the browser, and exception in the server,
> > > and the web console disabled. One cheap way to help prevent this
> > > problem is to add a challenge when any system module is stopped to
> > > ensure the user is aware that stopping a system module might result
> > > in rendering the web console unusable. The situation can be
> > > recovered via the CLI by subsequently starting the web console but
> > > this might not be obvious to the user and often a server restart is
> > > necessary before the CLI itself can function again.
> > >
> > > However, there is another problem that is much more serious. If
> > > the user selects "uninstall" on any of the modules listed above, in
> > > addition to the web console being disabled, the server itself is
> > > corrupted. In fact, in most cases the server cannot start once it
> > > is shutdown. AFAIK, there is no easy recovery from this. There is
> > > a challenge already provided to he user when uninstall is selected
> > > but it doesn't hint at the potential severity of the consequences.
> > >
> > > I'm thinking we should remove the uninstall capability from the
> > > system module view in the web console until we have more pluggable
> > > components that can be installed/uninstalled without crippling the
> > > entire server. A challenge (even if worded more strongly) just
> > > doesn't seem sufficient. Of course we have this same exposure with
> > > the CLI but it isn't quite as easy to shoot yourself in the foot
> > > there with just 2 mouse clicks. Thoughts?
> > >
> > > Joe
> > >
> >
> >
> >
>
Re: Too easy to kill the server using the web console
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
It probably would still be good to have some text like "WARNING: only
expert users will be able to restart the server after this is done."
Just seeing a list of components to be stopped won't necessarily clue
in "the average user" to the potential impact... But of course we'd
only want to display that if it was really the case, so perhaps we can
just detect whether the really important startup-fails-without-this
modules are in the dependency list.
Thanks,
Aaron
On 8/28/07, David Jencks <da...@yahoo.com> wrote:
> I don't like prohibiting people from doing stuff because we think we
> know better. I think there are valid reasons to stop and uninstall
> most of these modules, although you may need to be an expert to be
> able to start the server afterwards.
>
> How about if for both stop and uninstall we show a list of the
> modules that will be stopped or rendered inoperable as a result?
> This would be the transitive closure of the "child" view in the
> modules pages.
>
> thanks
> david jencks
>
> On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote:
>
> > GERONIMO-3401 ( https://issues.apache.org/jira/browse/
> > GERONIMO-3401 ) records a problem where it is possible for the user
> > to cripple the web console, the server or both with 1 or 2 mouse
> > clicks.
> >
> > When stopping some system-modules such as the following from the
> > web console, the web console itself is also stopped due to direct
> > and transitive dependencies:
> > - activemq-broker
> > - connector-deployer
> > - geronimo-gbean-deployer
> > - j2ee-corba-yoko
> > - j2ee-deployer
> > - j2ee-security
> > - j2ee-server
> > - j2ee-system
> > - jasper
> > - jee-specs
> > - openejb
> > - openjpa
> > - rmi-naming
> > - server-security-config
> > - tomcat6
> > - tomcat6-deployer
> > - jetty6
> > - jetty6-deployer
> > - transaction
> > - webservices-common
> > - xmlbeans
> >
> >
> > The result is an error in the browser, and exception in the server,
> > and the web console disabled. One cheap way to help prevent this
> > problem is to add a challenge when any system module is stopped to
> > ensure the user is aware that stopping a system module might result
> > in rendering the web console unusable. The situation can be
> > recovered via the CLI by subsequently starting the web console but
> > this might not be obvious to the user and often a server restart is
> > necessary before the CLI itself can function again.
> >
> > However, there is another problem that is much more serious. If
> > the user selects "uninstall" on any of the modules listed above, in
> > addition to the web console being disabled, the server itself is
> > corrupted. In fact, in most cases the server cannot start once it
> > is shutdown. AFAIK, there is no easy recovery from this. There is
> > a challenge already provided to he user when uninstall is selected
> > but it doesn't hint at the potential severity of the consequences.
> >
> > I'm thinking we should remove the uninstall capability from the
> > system module view in the web console until we have more pluggable
> > components that can be installed/uninstalled without crippling the
> > entire server. A challenge (even if worded more strongly) just
> > doesn't seem sufficient. Of course we have this same exposure with
> > the CLI but it isn't quite as easy to shoot yourself in the foot
> > there with just 2 mouse clicks. Thoughts?
> >
> > Joe
> >
>
>
>
Re: Too easy to kill the server using the web console
Posted by David Jencks <da...@yahoo.com>.
I don't like prohibiting people from doing stuff because we think we
know better. I think there are valid reasons to stop and uninstall
most of these modules, although you may need to be an expert to be
able to start the server afterwards.
How about if for both stop and uninstall we show a list of the
modules that will be stopped or rendered inoperable as a result?
This would be the transitive closure of the "child" view in the
modules pages.
thanks
david jencks
On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote:
> GERONIMO-3401 ( https://issues.apache.org/jira/browse/
> GERONIMO-3401 ) records a problem where it is possible for the user
> to cripple the web console, the server or both with 1 or 2 mouse
> clicks.
>
> When stopping some system-modules such as the following from the
> web console, the web console itself is also stopped due to direct
> and transitive dependencies:
> - activemq-broker
> - connector-deployer
> - geronimo-gbean-deployer
> - j2ee-corba-yoko
> - j2ee-deployer
> - j2ee-security
> - j2ee-server
> - j2ee-system
> - jasper
> - jee-specs
> - openejb
> - openjpa
> - rmi-naming
> - server-security-config
> - tomcat6
> - tomcat6-deployer
> - jetty6
> - jetty6-deployer
> - transaction
> - webservices-common
> - xmlbeans
>
>
> The result is an error in the browser, and exception in the server,
> and the web console disabled. One cheap way to help prevent this
> problem is to add a challenge when any system module is stopped to
> ensure the user is aware that stopping a system module might result
> in rendering the web console unusable. The situation can be
> recovered via the CLI by subsequently starting the web console but
> this might not be obvious to the user and often a server restart is
> necessary before the CLI itself can function again.
>
> However, there is another problem that is much more serious. If
> the user selects "uninstall" on any of the modules listed above, in
> addition to the web console being disabled, the server itself is
> corrupted. In fact, in most cases the server cannot start once it
> is shutdown. AFAIK, there is no easy recovery from this. There is
> a challenge already provided to he user when uninstall is selected
> but it doesn't hint at the potential severity of the consequences.
>
> I'm thinking we should remove the uninstall capability from the
> system module view in the web console until we have more pluggable
> components that can be installed/uninstalled without crippling the
> entire server. A challenge (even if worded more strongly) just
> doesn't seem sufficient. Of course we have this same exposure with
> the CLI but it isn't quite as easy to shoot yourself in the foot
> there with just 2 mouse clicks. Thoughts?
>
> Joe
>
Re: Too easy to kill the server using the web console
Posted by "Erik B. Craig" <gi...@gmail.com>.
Joe,
I did actually not-so-gracefully stumble into this previously, so I do know
the pain it can cause.
I think perhaps the best behavior in this situation might be to not only
prevent removal of components that would cripple the console, but also
display a prompt when it is attempted saying something along the lines of
"This component must be removed manually from command line, as doing so will
render the admin console useless".
On 8/28/07, Joe Bohn <jo...@earthlink.net> wrote:
>
> GERONIMO-3401 ( https://issues.apache.org/jira/browse/GERONIMO-3401 )
> records a problem where it is possible for the user to cripple the web
> console, the server or both with 1 or 2 mouse clicks.
>
> When stopping some system-modules such as the following from the web
> console, the web console itself is also stopped due to direct and
> transitive dependencies:
> - activemq-broker
> - connector-deployer
> - geronimo-gbean-deployer
> - j2ee-corba-yoko
> - j2ee-deployer
> - j2ee-security
> - j2ee-server
> - j2ee-system
> - jasper
> - jee-specs
> - openejb
> - openjpa
> - rmi-naming
> - server-security-config
> - tomcat6
> - tomcat6-deployer
> - jetty6
> - jetty6-deployer
> - transaction
> - webservices-common
> - xmlbeans
>
>
> The result is an error in the browser, and exception in the server, and
> the web console disabled. One cheap way to help prevent this problem is
> to add a challenge when any system module is stopped to ensure the user
> is aware that stopping a system module might result in rendering the web
> console unusable. The situation can be recovered via the CLI by
> subsequently starting the web console but this might not be obvious to
> the user and often a server restart is necessary before the CLI itself
> can function again.
>
> However, there is another problem that is much more serious. If the
> user selects "uninstall" on any of the modules listed above, in addition
> to the web console being disabled, the server itself is corrupted. In
> fact, in most cases the server cannot start once it is shutdown. AFAIK,
> there is no easy recovery from this. There is a challenge already
> provided to he user when uninstall is selected but it doesn't hint at
> the potential severity of the consequences.
>
> I'm thinking we should remove the uninstall capability from the system
> module view in the web console until we have more pluggable components
> that can be installed/uninstalled without crippling the entire server. A
> challenge (even if worded more strongly) just doesn't seem sufficient.
> Of course we have this same exposure with the CLI but it isn't quite as
> easy to shoot yourself in the foot there with just 2 mouse clicks.
> Thoughts?
>
> Joe
>
>
--
Erik B. Craig