You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jarek Gawor <jg...@gmail.com> on 2008/03/14 05:25:52 UTC
start-server command and default user credentials
I'm trying to restart the discussion on the start-server command and
the hard-coded user credentials to see if we can fix this somehow.
Right now, the start-server command will poll the server periodically
using JMX to see if the server started up ok. That's why it needs
username/password to check on the status of the server.
Jason below described one idea how we might fix/improve the
start-server command.
I'm wondering if we need to poll the server at all. If the server is
running in the foreground the user will know if the server started up
ok or not from looking at the console. And even if the server is
started up in the background, the command should return as soon as the
server process forked ok and not wait until the server finishes
starting up. So maybe we should separate the process of starting the
server from checking if the server started up ok. For example, add
isServerRunning or waitForServer gsh commands (which would require
creds) and make the start-server command just fork the server process
(no creds required).
Thoughts?
Jarek
On Fri, Feb 22, 2008 at 6:51 AM, Jason Dillon <ja...@planet57.com> wrote:
> We might be able to open a port on localhost during startup, which
> would only be used to provide status (like starting, started, shutting
> down). Then we wouldn't need to make a JMX connection to the server
> at all. Though if possible, a special anonymous system account with
> limited proviledges for remote JMX would be more ideal... though I've
> no idea if that is possible asis or if it would be easy to implement
> if its not there.
>
> Anyone have any other ideas?
>
> --jason
>
>
>
>
> On Feb 21, 2008, at 12:57 PM, Jarek Gawor wrote:
>
> > On Thu, Feb 21, 2008 at 2:35 PM, Jason Warner <ja...@gmail.com>
> > wrote:
> >>
> >>
> >> On Thu, Feb 21, 2008 at 1:36 PM, Jarek Gawor <jg...@gmail.com>
> >> wrote:
> >>> Yes, I've noticed that too. The deploy/* commands are not
> >>> 'integrated'
> >>> with the geronimo/* commands. Looks like the JMX connection is not
> >>> being shared between these groups of commands. We should be able to
> >>> fix that. Please open a bug. Also, I just noticed that if an user
> >>> changes the default user/password the geronimo/start-server command
> >>> might fail with an error.
> >>>
> >>> Jarek
> >>>
> >>>
> >>>
> >>>
> >>
> >> I just opened a jira for that original issue I mentioned.
> >> https://issues.apache.org/jira/browse/GERONIMO-3869
> >>
> >> I'm not sure I understand that second issue you mentioned.
> >
> > The start-server command has hardcoded username/password combination
> > and it cannot be specified on the command line. So if the password is
> > changed and if you start the server let's say with:
> >
> > geronimo/start-server --background --timeout 60
> >
> > You will see something like:
> >
> > .....
> > Geronimo Application Server started
> > <after <60 seconds>
> > ERROR Exception: Failed to start: Geronimo Server
> >
> > Even though the server started up fine but then becuase of the
> > exception it will be killed.
> >
> > Jarek
>
>
Re: start-server command and default user credentials
Posted by Donald Woods <dw...@apache.org>.
Agree
-Donald
Jarek Gawor wrote:
> On Sat, Mar 15, 2008 at 12:28 AM, Jason Dillon <ja...@planet57.com> wrote:
>> On Mar 15, 2008, at 12:34 AM, Donald Woods wrote:
>> > Jarek Gawor wrote:
>> >> Jason,
>> >> I thought TCK was using the maven plugin to start the server. I'm not
>> >> proposing to change that. But even if start-server command is used by
>> >> TCK, I don't think that alone should dictate how the command should
>> >> behave. I'm thinking what happens if you start any command in the
>> >> background in a regular shell or even use geronimo.sh run or
>>
>> The --background option is not intended to behave like a shells &
>> operator... and some daemons do fork right away and return while the
>> child continues, but other more robust daemons fork, then wait for the
>> child to become booted, then return, so that any error status can be
>> returned to the invoking shell for handling.
>>
>> IMO this is how Geronimo should behave...
>>
>> Adding a --wait or --nowait option might be useful, though I'd really
>> like to solve the username/passwd problem... I think we need any
>> anonymous way to query the status...
>
> Whether to poll and how to poll are two separate issues to me. I agree
> that we do need a way to anonymously query the status but I don't
> think we need to query the status in the normal/default case in the
> first place. When executing a script we'll need to know the status of
> the server and polling will be necessary but when starting the server
> in foreground polling is unnecessary.
>
> Jarek
>
Re: start-server command and default user credentials
Posted by Jason Dillon <ja...@planet57.com>.
The only data I was envisioning was a simple text status string,
similar to what you get when you telnet to a sendmail port.
--jason
On Mar 19, 2008, at 1:55 AM, Donald Woods wrote:
> I like the more secure option of requiring a uid/pwd, than potential
> exposing unwanted data to attackers....
>
> -Donald
>
>
> Jarek Gawor wrote:
>> Anymore more thoughts on this issue? If not, I guess I'll just add
>> options for specifying the username, password and port number as a
>> temporary solution to get this fixed for the 2.1.1 release.
>> Jarek
>> On Mon, Mar 17, 2008 at 11:01 AM, Jarek Gawor <jg...@gmail.com>
>> wrote:
>>> On Sat, Mar 15, 2008 at 12:28 AM, Jason Dillon
>>> <ja...@planet57.com> wrote:
>>> > On Mar 15, 2008, at 12:34 AM, Donald Woods wrote:
>>> > > Jarek Gawor wrote:
>>> > >> Jason,
>>> > >> I thought TCK was using the maven plugin to start the
>>> server. I'm not
>>> > >> proposing to change that. But even if start-server command
>>> is used by
>>> > >> TCK, I don't think that alone should dictate how the command
>>> should
>>> > >> behave. I'm thinking what happens if you start any command
>>> in the
>>> > >> background in a regular shell or even use geronimo.sh run or
>>> >
>>> > The --background option is not intended to behave like a shells &
>>> > operator... and some daemons do fork right away and return
>>> while the
>>> > child continues, but other more robust daemons fork, then wait
>>> for the
>>> > child to become booted, then return, so that any error status
>>> can be
>>> > returned to the invoking shell for handling.
>>> >
>>> > IMO this is how Geronimo should behave...
>>> >
>>> > Adding a --wait or --nowait option might be useful, though I'd
>>> really
>>> > like to solve the username/passwd problem... I think we need any
>>> > anonymous way to query the status...
>>>
>>> Whether to poll and how to poll are two separate issues to me. I
>>> agree
>>> that we do need a way to anonymously query the status but I don't
>>> think we need to query the status in the normal/default case in the
>>> first place. When executing a script we'll need to know the status
>>> of
>>> the server and polling will be necessary but when starting the
>>> server
>>> in foreground polling is unnecessary.
>>>
>>> Jarek
>>>
Re: start-server command and default user credentials
Posted by Donald Woods <dw...@apache.org>.
I like the more secure option of requiring a uid/pwd, than potential
exposing unwanted data to attackers....
-Donald
Jarek Gawor wrote:
> Anymore more thoughts on this issue? If not, I guess I'll just add
> options for specifying the username, password and port number as a
> temporary solution to get this fixed for the 2.1.1 release.
>
> Jarek
>
> On Mon, Mar 17, 2008 at 11:01 AM, Jarek Gawor <jg...@gmail.com> wrote:
>> On Sat, Mar 15, 2008 at 12:28 AM, Jason Dillon <ja...@planet57.com> wrote:
>> > On Mar 15, 2008, at 12:34 AM, Donald Woods wrote:
>> > > Jarek Gawor wrote:
>> > >> Jason,
>> > >> I thought TCK was using the maven plugin to start the server. I'm not
>> > >> proposing to change that. But even if start-server command is used by
>> > >> TCK, I don't think that alone should dictate how the command should
>> > >> behave. I'm thinking what happens if you start any command in the
>> > >> background in a regular shell or even use geronimo.sh run or
>> >
>> > The --background option is not intended to behave like a shells &
>> > operator... and some daemons do fork right away and return while the
>> > child continues, but other more robust daemons fork, then wait for the
>> > child to become booted, then return, so that any error status can be
>> > returned to the invoking shell for handling.
>> >
>> > IMO this is how Geronimo should behave...
>> >
>> > Adding a --wait or --nowait option might be useful, though I'd really
>> > like to solve the username/passwd problem... I think we need any
>> > anonymous way to query the status...
>>
>> Whether to poll and how to poll are two separate issues to me. I agree
>> that we do need a way to anonymously query the status but I don't
>> think we need to query the status in the normal/default case in the
>> first place. When executing a script we'll need to know the status of
>> the server and polling will be necessary but when starting the server
>> in foreground polling is unnecessary.
>>
>> Jarek
>>
>
Re: start-server command and default user credentials
Posted by Jarek Gawor <jg...@gmail.com>.
Anymore more thoughts on this issue? If not, I guess I'll just add
options for specifying the username, password and port number as a
temporary solution to get this fixed for the 2.1.1 release.
Jarek
On Mon, Mar 17, 2008 at 11:01 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Sat, Mar 15, 2008 at 12:28 AM, Jason Dillon <ja...@planet57.com> wrote:
> > On Mar 15, 2008, at 12:34 AM, Donald Woods wrote:
> > > Jarek Gawor wrote:
> > >> Jason,
> > >> I thought TCK was using the maven plugin to start the server. I'm not
> > >> proposing to change that. But even if start-server command is used by
> > >> TCK, I don't think that alone should dictate how the command should
> > >> behave. I'm thinking what happens if you start any command in the
> > >> background in a regular shell or even use geronimo.sh run or
> >
> > The --background option is not intended to behave like a shells &
> > operator... and some daemons do fork right away and return while the
> > child continues, but other more robust daemons fork, then wait for the
> > child to become booted, then return, so that any error status can be
> > returned to the invoking shell for handling.
> >
> > IMO this is how Geronimo should behave...
> >
> > Adding a --wait or --nowait option might be useful, though I'd really
> > like to solve the username/passwd problem... I think we need any
> > anonymous way to query the status...
>
> Whether to poll and how to poll are two separate issues to me. I agree
> that we do need a way to anonymously query the status but I don't
> think we need to query the status in the normal/default case in the
> first place. When executing a script we'll need to know the status of
> the server and polling will be necessary but when starting the server
> in foreground polling is unnecessary.
>
> Jarek
>
Re: start-server command and default user credentials
Posted by Jarek Gawor <jg...@gmail.com>.
On Sat, Mar 15, 2008 at 12:28 AM, Jason Dillon <ja...@planet57.com> wrote:
> On Mar 15, 2008, at 12:34 AM, Donald Woods wrote:
> > Jarek Gawor wrote:
> >> Jason,
> >> I thought TCK was using the maven plugin to start the server. I'm not
> >> proposing to change that. But even if start-server command is used by
> >> TCK, I don't think that alone should dictate how the command should
> >> behave. I'm thinking what happens if you start any command in the
> >> background in a regular shell or even use geronimo.sh run or
>
> The --background option is not intended to behave like a shells &
> operator... and some daemons do fork right away and return while the
> child continues, but other more robust daemons fork, then wait for the
> child to become booted, then return, so that any error status can be
> returned to the invoking shell for handling.
>
> IMO this is how Geronimo should behave...
>
> Adding a --wait or --nowait option might be useful, though I'd really
> like to solve the username/passwd problem... I think we need any
> anonymous way to query the status...
Whether to poll and how to poll are two separate issues to me. I agree
that we do need a way to anonymously query the status but I don't
think we need to query the status in the normal/default case in the
first place. When executing a script we'll need to know the status of
the server and polling will be necessary but when starting the server
in foreground polling is unnecessary.
Jarek
Re: start-server command and default user credentials
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 15, 2008, at 12:34 AM, Donald Woods wrote:
> Jarek Gawor wrote:
>> Jason,
>> I thought TCK was using the maven plugin to start the server. I'm not
>> proposing to change that. But even if start-server command is used by
>> TCK, I don't think that alone should dictate how the command should
>> behave. I'm thinking what happens if you start any command in the
>> background in a regular shell or even use geronimo.sh run or
The --background option is not intended to behave like a shells &
operator... and some daemons do fork right away and return while the
child continues, but other more robust daemons fork, then wait for the
child to become booted, then return, so that any error status can be
returned to the invoking shell for handling.
IMO this is how Geronimo should behave...
Adding a --wait or --nowait option might be useful, though I'd really
like to solve the username/passwd problem... I think we need any
anonymous way to query the status...
--jason
>> geronimo.sh start. It does not tell you if the command finished
>> starting up ok. So start-server command is unqiue in that respect and
>> I think it would be better if the behaviour was consistent.
>> Maybe as a compromise, we could add -wait option to the start-server
>> command and only poll the server for successful start up when that
>> option is specified.
>
> Sounds like a good approach.
>
> Also, couldn't we require the user to provide the user/password if
> they want to use the -wait option or require them to have used the
> deployer.sh login command to store the correct credentials first?
>
> -Donald
>
>> Jarek
>> On Fri, Mar 14, 2008 at 7:16 AM, Jason Dillon <ja...@planet57.com>
>> wrote:
>>> The wait for start behavior is required for proper TCK automation,
>>> so
>>> that once the start-server command finishes, we know the server
>>> is up
>>> and running, else there is some problem.
>>>
>>> I imagine that users also want this type of feedback when they run
>>> the
>>> start-server command. I think it would be a bad idea to run the
>>> command and return success and then force the user to use an
>>> additional command or inspect the logs (or process tree) to
>>> determine
>>> if the server was started.
>>>
>>> The problem here is that to access this information we need an
>>> authenticated connection via JMX. So if we can provide a limited
>>> system-only account with a passwd that is static then we can get
>>> this
>>> information to allow the command to work even when the "system"
>>> account passwd has been changed. Alternatively we can provide
>>> another
>>> mechanism to allow tools to query the running status of the server.
>>> There is no security risk here, just need to provide some simple
>>> mechanism to allow tools to determine the state of the server.
>>> Which
>>> IMO seems very reasonable to me.
>>>
>>> I'd like to not see this functionality tossed into a separate
>>> command,
>>> but have the feature exposed to all tools.
>>>
>>> * * *
>>>
>>> David, how hard is it to implement a JMX authentication and
>>> limitation
>>> system which would only grant a specific user access to invoke/get
>>> operations/attributes on a set of gbeans?
>>>
>>> --jason
>>>
>>>
>>>
>>>
>>> On Mar 14, 2008, at 12:44 PM, David Jencks wrote:
>>>
>>> >
>>> > On Mar 13, 2008, at 9:25 PM, Jarek Gawor wrote:
>>> >
>>> >> I'm trying to restart the discussion on the start-server
>>> command and
>>> >> the hard-coded user credentials to see if we can fix this
>>> somehow.
>>> >>
>>> >> Right now, the start-server command will poll the server
>>> periodically
>>> >> using JMX to see if the server started up ok. That's why it needs
>>> >> username/password to check on the status of the server.
>>> >>
>>> >> Jason below described one idea how we might fix/improve the
>>> >> start-server command.
>>> >>
>>> >> I'm wondering if we need to poll the server at all. If the
>>> server is
>>> >> running in the foreground the user will know if the server
>>> started up
>>> >> ok or not from looking at the console. And even if the server is
>>> >> started up in the background, the command should return as soon
>>> as
>>> >> the
>>> >> server process forked ok and not wait until the server finishes
>>> >> starting up. So maybe we should separate the process of
>>> starting the
>>> >> server from checking if the server started up ok. For example,
>>> add
>>> >> isServerRunning or waitForServer gsh commands (which would
>>> require
>>> >> creds) and make the start-server command just fork the server
>>> process
>>> >> (no creds required).
>>> >>
>>> >> Thoughts?
>>> >
>>> > OK. IIRC the idea behind the current behavior was so you could
>>> > write scripts that start the server, then do stuff once it is
>>> > running. However I doubt this was explicit for the gshell
>>> > command... Anyway I'd be happy with a separate
>>> > "isServerRunning(boolean wait)" type command.
>>> >
>>> > thanks
>>> > david jencks
>>> >
>>> >>
>>> >> Jarek
>>> >>
>>> >> On Fri, Feb 22, 2008 at 6:51 AM, Jason Dillon
>>> <ja...@planet57.com>
>>> >> wrote:
>>> >>> We might be able to open a port on localhost during startup,
>>> which
>>> >>> would only be used to provide status (like starting, started,
>>> >>> shutting
>>> >>> down). Then we wouldn't need to make a JMX connection to the
>>> server
>>> >>> at all. Though if possible, a special anonymous system
>>> account with
>>> >>> limited proviledges for remote JMX would be more ideal... though
>>> >>> I've
>>> >>> no idea if that is possible asis or if it would be easy to
>>> implement
>>> >>> if its not there.
>>> >>>
>>> >>> Anyone have any other ideas?
>>> >>>
>>> >>> --jason
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Feb 21, 2008, at 12:57 PM, Jarek Gawor wrote:
>>> >>>
>>> >>>> On Thu, Feb 21, 2008 at 2:35 PM, Jason Warner
>>> <ja...@gmail.com>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>>
>>> >>>>> On Thu, Feb 21, 2008 at 1:36 PM, Jarek Gawor
>>> <jg...@gmail.com>
>>> >>>>> wrote:
>>> >>>>>> Yes, I've noticed that too. The deploy/* commands are not
>>> >>>>>> 'integrated'
>>> >>>>>> with the geronimo/* commands. Looks like the JMX connection
>>> is
>>> >>>>>> not
>>> >>>>>> being shared between these groups of commands. We should be
>>> >>>>>> able to
>>> >>>>>> fix that. Please open a bug. Also, I just noticed that if
>>> an user
>>> >>>>>> changes the default user/password the geronimo/start-server
>>> >>>>>> command
>>> >>>>>> might fail with an error.
>>> >>>>>>
>>> >>>>>> Jarek
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>> I just opened a jira for that original issue I mentioned.
>>> >>>>> https://issues.apache.org/jira/browse/GERONIMO-3869
>>> >>>>>
>>> >>>>> I'm not sure I understand that second issue you mentioned.
>>> >>>>
>>> >>>> The start-server command has hardcoded username/password
>>> >>>> combination
>>> >>>> and it cannot be specified on the command line. So if the
>>> >>>> password is
>>> >>>> changed and if you start the server let's say with:
>>> >>>>
>>> >>>> geronimo/start-server --background --timeout 60
>>> >>>>
>>> >>>> You will see something like:
>>> >>>>
>>> >>>> .....
>>> >>>> Geronimo Application Server started
>>> >>>> <after <60 seconds>
>>> >>>> ERROR Exception: Failed to start: Geronimo Server
>>> >>>>
>>> >>>> Even though the server started up fine but then becuase of the
>>> >>>> exception it will be killed.
>>> >>>>
>>> >>>> Jarek
>>> >>>
>>> >>>
>>> >
>>>
>>>
Re: start-server command and default user credentials
Posted by Donald Woods <dw...@apache.org>.
Jarek Gawor wrote:
> Jason,
>
> I thought TCK was using the maven plugin to start the server. I'm not
> proposing to change that. But even if start-server command is used by
> TCK, I don't think that alone should dictate how the command should
> behave. I'm thinking what happens if you start any command in the
> background in a regular shell or even use geronimo.sh run or
> geronimo.sh start. It does not tell you if the command finished
> starting up ok. So start-server command is unqiue in that respect and
> I think it would be better if the behaviour was consistent.
>
> Maybe as a compromise, we could add -wait option to the start-server
> command and only poll the server for successful start up when that
> option is specified.
Sounds like a good approach.
Also, couldn't we require the user to provide the user/password if they
want to use the -wait option or require them to have used the
deployer.sh login command to store the correct credentials first?
-Donald
>
> Jarek
>
> On Fri, Mar 14, 2008 at 7:16 AM, Jason Dillon <ja...@planet57.com> wrote:
>> The wait for start behavior is required for proper TCK automation, so
>> that once the start-server command finishes, we know the server is up
>> and running, else there is some problem.
>>
>> I imagine that users also want this type of feedback when they run the
>> start-server command. I think it would be a bad idea to run the
>> command and return success and then force the user to use an
>> additional command or inspect the logs (or process tree) to determine
>> if the server was started.
>>
>> The problem here is that to access this information we need an
>> authenticated connection via JMX. So if we can provide a limited
>> system-only account with a passwd that is static then we can get this
>> information to allow the command to work even when the "system"
>> account passwd has been changed. Alternatively we can provide another
>> mechanism to allow tools to query the running status of the server.
>> There is no security risk here, just need to provide some simple
>> mechanism to allow tools to determine the state of the server. Which
>> IMO seems very reasonable to me.
>>
>> I'd like to not see this functionality tossed into a separate command,
>> but have the feature exposed to all tools.
>>
>> * * *
>>
>> David, how hard is it to implement a JMX authentication and limitation
>> system which would only grant a specific user access to invoke/get
>> operations/attributes on a set of gbeans?
>>
>> --jason
>>
>>
>>
>>
>> On Mar 14, 2008, at 12:44 PM, David Jencks wrote:
>>
>> >
>> > On Mar 13, 2008, at 9:25 PM, Jarek Gawor wrote:
>> >
>> >> I'm trying to restart the discussion on the start-server command and
>> >> the hard-coded user credentials to see if we can fix this somehow.
>> >>
>> >> Right now, the start-server command will poll the server periodically
>> >> using JMX to see if the server started up ok. That's why it needs
>> >> username/password to check on the status of the server.
>> >>
>> >> Jason below described one idea how we might fix/improve the
>> >> start-server command.
>> >>
>> >> I'm wondering if we need to poll the server at all. If the server is
>> >> running in the foreground the user will know if the server started up
>> >> ok or not from looking at the console. And even if the server is
>> >> started up in the background, the command should return as soon as
>> >> the
>> >> server process forked ok and not wait until the server finishes
>> >> starting up. So maybe we should separate the process of starting the
>> >> server from checking if the server started up ok. For example, add
>> >> isServerRunning or waitForServer gsh commands (which would require
>> >> creds) and make the start-server command just fork the server process
>> >> (no creds required).
>> >>
>> >> Thoughts?
>> >
>> > OK. IIRC the idea behind the current behavior was so you could
>> > write scripts that start the server, then do stuff once it is
>> > running. However I doubt this was explicit for the gshell
>> > command... Anyway I'd be happy with a separate
>> > "isServerRunning(boolean wait)" type command.
>> >
>> > thanks
>> > david jencks
>> >
>> >>
>> >> Jarek
>> >>
>> >> On Fri, Feb 22, 2008 at 6:51 AM, Jason Dillon <ja...@planet57.com>
>> >> wrote:
>> >>> We might be able to open a port on localhost during startup, which
>> >>> would only be used to provide status (like starting, started,
>> >>> shutting
>> >>> down). Then we wouldn't need to make a JMX connection to the server
>> >>> at all. Though if possible, a special anonymous system account with
>> >>> limited proviledges for remote JMX would be more ideal... though
>> >>> I've
>> >>> no idea if that is possible asis or if it would be easy to implement
>> >>> if its not there.
>> >>>
>> >>> Anyone have any other ideas?
>> >>>
>> >>> --jason
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Feb 21, 2008, at 12:57 PM, Jarek Gawor wrote:
>> >>>
>> >>>> On Thu, Feb 21, 2008 at 2:35 PM, Jason Warner <ja...@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Feb 21, 2008 at 1:36 PM, Jarek Gawor <jg...@gmail.com>
>> >>>>> wrote:
>> >>>>>> Yes, I've noticed that too. The deploy/* commands are not
>> >>>>>> 'integrated'
>> >>>>>> with the geronimo/* commands. Looks like the JMX connection is
>> >>>>>> not
>> >>>>>> being shared between these groups of commands. We should be
>> >>>>>> able to
>> >>>>>> fix that. Please open a bug. Also, I just noticed that if an user
>> >>>>>> changes the default user/password the geronimo/start-server
>> >>>>>> command
>> >>>>>> might fail with an error.
>> >>>>>>
>> >>>>>> Jarek
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>> I just opened a jira for that original issue I mentioned.
>> >>>>> https://issues.apache.org/jira/browse/GERONIMO-3869
>> >>>>>
>> >>>>> I'm not sure I understand that second issue you mentioned.
>> >>>>
>> >>>> The start-server command has hardcoded username/password
>> >>>> combination
>> >>>> and it cannot be specified on the command line. So if the
>> >>>> password is
>> >>>> changed and if you start the server let's say with:
>> >>>>
>> >>>> geronimo/start-server --background --timeout 60
>> >>>>
>> >>>> You will see something like:
>> >>>>
>> >>>> .....
>> >>>> Geronimo Application Server started
>> >>>> <after <60 seconds>
>> >>>> ERROR Exception: Failed to start: Geronimo Server
>> >>>>
>> >>>> Even though the server started up fine but then becuase of the
>> >>>> exception it will be killed.
>> >>>>
>> >>>> Jarek
>> >>>
>> >>>
>> >
>>
>>
>
Re: start-server command and default user credentials
Posted by Jarek Gawor <jg...@gmail.com>.
Jason,
I thought TCK was using the maven plugin to start the server. I'm not
proposing to change that. But even if start-server command is used by
TCK, I don't think that alone should dictate how the command should
behave. I'm thinking what happens if you start any command in the
background in a regular shell or even use geronimo.sh run or
geronimo.sh start. It does not tell you if the command finished
starting up ok. So start-server command is unqiue in that respect and
I think it would be better if the behaviour was consistent.
Maybe as a compromise, we could add -wait option to the start-server
command and only poll the server for successful start up when that
option is specified.
Jarek
On Fri, Mar 14, 2008 at 7:16 AM, Jason Dillon <ja...@planet57.com> wrote:
> The wait for start behavior is required for proper TCK automation, so
> that once the start-server command finishes, we know the server is up
> and running, else there is some problem.
>
> I imagine that users also want this type of feedback when they run the
> start-server command. I think it would be a bad idea to run the
> command and return success and then force the user to use an
> additional command or inspect the logs (or process tree) to determine
> if the server was started.
>
> The problem here is that to access this information we need an
> authenticated connection via JMX. So if we can provide a limited
> system-only account with a passwd that is static then we can get this
> information to allow the command to work even when the "system"
> account passwd has been changed. Alternatively we can provide another
> mechanism to allow tools to query the running status of the server.
> There is no security risk here, just need to provide some simple
> mechanism to allow tools to determine the state of the server. Which
> IMO seems very reasonable to me.
>
> I'd like to not see this functionality tossed into a separate command,
> but have the feature exposed to all tools.
>
> * * *
>
> David, how hard is it to implement a JMX authentication and limitation
> system which would only grant a specific user access to invoke/get
> operations/attributes on a set of gbeans?
>
> --jason
>
>
>
>
> On Mar 14, 2008, at 12:44 PM, David Jencks wrote:
>
> >
> > On Mar 13, 2008, at 9:25 PM, Jarek Gawor wrote:
> >
> >> I'm trying to restart the discussion on the start-server command and
> >> the hard-coded user credentials to see if we can fix this somehow.
> >>
> >> Right now, the start-server command will poll the server periodically
> >> using JMX to see if the server started up ok. That's why it needs
> >> username/password to check on the status of the server.
> >>
> >> Jason below described one idea how we might fix/improve the
> >> start-server command.
> >>
> >> I'm wondering if we need to poll the server at all. If the server is
> >> running in the foreground the user will know if the server started up
> >> ok or not from looking at the console. And even if the server is
> >> started up in the background, the command should return as soon as
> >> the
> >> server process forked ok and not wait until the server finishes
> >> starting up. So maybe we should separate the process of starting the
> >> server from checking if the server started up ok. For example, add
> >> isServerRunning or waitForServer gsh commands (which would require
> >> creds) and make the start-server command just fork the server process
> >> (no creds required).
> >>
> >> Thoughts?
> >
> > OK. IIRC the idea behind the current behavior was so you could
> > write scripts that start the server, then do stuff once it is
> > running. However I doubt this was explicit for the gshell
> > command... Anyway I'd be happy with a separate
> > "isServerRunning(boolean wait)" type command.
> >
> > thanks
> > david jencks
> >
> >>
> >> Jarek
> >>
> >> On Fri, Feb 22, 2008 at 6:51 AM, Jason Dillon <ja...@planet57.com>
> >> wrote:
> >>> We might be able to open a port on localhost during startup, which
> >>> would only be used to provide status (like starting, started,
> >>> shutting
> >>> down). Then we wouldn't need to make a JMX connection to the server
> >>> at all. Though if possible, a special anonymous system account with
> >>> limited proviledges for remote JMX would be more ideal... though
> >>> I've
> >>> no idea if that is possible asis or if it would be easy to implement
> >>> if its not there.
> >>>
> >>> Anyone have any other ideas?
> >>>
> >>> --jason
> >>>
> >>>
> >>>
> >>>
> >>> On Feb 21, 2008, at 12:57 PM, Jarek Gawor wrote:
> >>>
> >>>> On Thu, Feb 21, 2008 at 2:35 PM, Jason Warner <ja...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> On Thu, Feb 21, 2008 at 1:36 PM, Jarek Gawor <jg...@gmail.com>
> >>>>> wrote:
> >>>>>> Yes, I've noticed that too. The deploy/* commands are not
> >>>>>> 'integrated'
> >>>>>> with the geronimo/* commands. Looks like the JMX connection is
> >>>>>> not
> >>>>>> being shared between these groups of commands. We should be
> >>>>>> able to
> >>>>>> fix that. Please open a bug. Also, I just noticed that if an user
> >>>>>> changes the default user/password the geronimo/start-server
> >>>>>> command
> >>>>>> might fail with an error.
> >>>>>>
> >>>>>> Jarek
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> I just opened a jira for that original issue I mentioned.
> >>>>> https://issues.apache.org/jira/browse/GERONIMO-3869
> >>>>>
> >>>>> I'm not sure I understand that second issue you mentioned.
> >>>>
> >>>> The start-server command has hardcoded username/password
> >>>> combination
> >>>> and it cannot be specified on the command line. So if the
> >>>> password is
> >>>> changed and if you start the server let's say with:
> >>>>
> >>>> geronimo/start-server --background --timeout 60
> >>>>
> >>>> You will see something like:
> >>>>
> >>>> .....
> >>>> Geronimo Application Server started
> >>>> <after <60 seconds>
> >>>> ERROR Exception: Failed to start: Geronimo Server
> >>>>
> >>>> Even though the server started up fine but then becuase of the
> >>>> exception it will be killed.
> >>>>
> >>>> Jarek
> >>>
> >>>
> >
>
>
Re: start-server command and default user credentials
Posted by Jason Dillon <ja...@planet57.com>.
The wait for start behavior is required for proper TCK automation, so
that once the start-server command finishes, we know the server is up
and running, else there is some problem.
I imagine that users also want this type of feedback when they run the
start-server command. I think it would be a bad idea to run the
command and return success and then force the user to use an
additional command or inspect the logs (or process tree) to determine
if the server was started.
The problem here is that to access this information we need an
authenticated connection via JMX. So if we can provide a limited
system-only account with a passwd that is static then we can get this
information to allow the command to work even when the "system"
account passwd has been changed. Alternatively we can provide another
mechanism to allow tools to query the running status of the server.
There is no security risk here, just need to provide some simple
mechanism to allow tools to determine the state of the server. Which
IMO seems very reasonable to me.
I'd like to not see this functionality tossed into a separate command,
but have the feature exposed to all tools.
* * *
David, how hard is it to implement a JMX authentication and limitation
system which would only grant a specific user access to invoke/get
operations/attributes on a set of gbeans?
--jason
On Mar 14, 2008, at 12:44 PM, David Jencks wrote:
>
> On Mar 13, 2008, at 9:25 PM, Jarek Gawor wrote:
>
>> I'm trying to restart the discussion on the start-server command and
>> the hard-coded user credentials to see if we can fix this somehow.
>>
>> Right now, the start-server command will poll the server periodically
>> using JMX to see if the server started up ok. That's why it needs
>> username/password to check on the status of the server.
>>
>> Jason below described one idea how we might fix/improve the
>> start-server command.
>>
>> I'm wondering if we need to poll the server at all. If the server is
>> running in the foreground the user will know if the server started up
>> ok or not from looking at the console. And even if the server is
>> started up in the background, the command should return as soon as
>> the
>> server process forked ok and not wait until the server finishes
>> starting up. So maybe we should separate the process of starting the
>> server from checking if the server started up ok. For example, add
>> isServerRunning or waitForServer gsh commands (which would require
>> creds) and make the start-server command just fork the server process
>> (no creds required).
>>
>> Thoughts?
>
> OK. IIRC the idea behind the current behavior was so you could
> write scripts that start the server, then do stuff once it is
> running. However I doubt this was explicit for the gshell
> command... Anyway I'd be happy with a separate
> "isServerRunning(boolean wait)" type command.
>
> thanks
> david jencks
>
>>
>> Jarek
>>
>> On Fri, Feb 22, 2008 at 6:51 AM, Jason Dillon <ja...@planet57.com>
>> wrote:
>>> We might be able to open a port on localhost during startup, which
>>> would only be used to provide status (like starting, started,
>>> shutting
>>> down). Then we wouldn't need to make a JMX connection to the server
>>> at all. Though if possible, a special anonymous system account with
>>> limited proviledges for remote JMX would be more ideal... though
>>> I've
>>> no idea if that is possible asis or if it would be easy to implement
>>> if its not there.
>>>
>>> Anyone have any other ideas?
>>>
>>> --jason
>>>
>>>
>>>
>>>
>>> On Feb 21, 2008, at 12:57 PM, Jarek Gawor wrote:
>>>
>>>> On Thu, Feb 21, 2008 at 2:35 PM, Jason Warner <ja...@gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Thu, Feb 21, 2008 at 1:36 PM, Jarek Gawor <jg...@gmail.com>
>>>>> wrote:
>>>>>> Yes, I've noticed that too. The deploy/* commands are not
>>>>>> 'integrated'
>>>>>> with the geronimo/* commands. Looks like the JMX connection is
>>>>>> not
>>>>>> being shared between these groups of commands. We should be
>>>>>> able to
>>>>>> fix that. Please open a bug. Also, I just noticed that if an user
>>>>>> changes the default user/password the geronimo/start-server
>>>>>> command
>>>>>> might fail with an error.
>>>>>>
>>>>>> Jarek
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> I just opened a jira for that original issue I mentioned.
>>>>> https://issues.apache.org/jira/browse/GERONIMO-3869
>>>>>
>>>>> I'm not sure I understand that second issue you mentioned.
>>>>
>>>> The start-server command has hardcoded username/password
>>>> combination
>>>> and it cannot be specified on the command line. So if the
>>>> password is
>>>> changed and if you start the server let's say with:
>>>>
>>>> geronimo/start-server --background --timeout 60
>>>>
>>>> You will see something like:
>>>>
>>>> .....
>>>> Geronimo Application Server started
>>>> <after <60 seconds>
>>>> ERROR Exception: Failed to start: Geronimo Server
>>>>
>>>> Even though the server started up fine but then becuase of the
>>>> exception it will be killed.
>>>>
>>>> Jarek
>>>
>>>
>
Re: start-server command and default user credentials
Posted by David Jencks <da...@yahoo.com>.
On Mar 13, 2008, at 9:25 PM, Jarek Gawor wrote:
> I'm trying to restart the discussion on the start-server command and
> the hard-coded user credentials to see if we can fix this somehow.
>
> Right now, the start-server command will poll the server periodically
> using JMX to see if the server started up ok. That's why it needs
> username/password to check on the status of the server.
>
> Jason below described one idea how we might fix/improve the
> start-server command.
>
> I'm wondering if we need to poll the server at all. If the server is
> running in the foreground the user will know if the server started up
> ok or not from looking at the console. And even if the server is
> started up in the background, the command should return as soon as the
> server process forked ok and not wait until the server finishes
> starting up. So maybe we should separate the process of starting the
> server from checking if the server started up ok. For example, add
> isServerRunning or waitForServer gsh commands (which would require
> creds) and make the start-server command just fork the server process
> (no creds required).
>
> Thoughts?
OK. IIRC the idea behind the current behavior was so you could write
scripts that start the server, then do stuff once it is running.
However I doubt this was explicit for the gshell command... Anyway
I'd be happy with a separate "isServerRunning(boolean wait)" type
command.
thanks
david jencks
>
> Jarek
>
> On Fri, Feb 22, 2008 at 6:51 AM, Jason Dillon <ja...@planet57.com>
> wrote:
>> We might be able to open a port on localhost during startup, which
>> would only be used to provide status (like starting, started,
>> shutting
>> down). Then we wouldn't need to make a JMX connection to the server
>> at all. Though if possible, a special anonymous system account with
>> limited proviledges for remote JMX would be more ideal... though
>> I've
>> no idea if that is possible asis or if it would be easy to implement
>> if its not there.
>>
>> Anyone have any other ideas?
>>
>> --jason
>>
>>
>>
>>
>> On Feb 21, 2008, at 12:57 PM, Jarek Gawor wrote:
>>
>>> On Thu, Feb 21, 2008 at 2:35 PM, Jason Warner <ja...@gmail.com>
>>> wrote:
>>>>
>>>>
>>>> On Thu, Feb 21, 2008 at 1:36 PM, Jarek Gawor <jg...@gmail.com>
>>>> wrote:
>>>>> Yes, I've noticed that too. The deploy/* commands are not
>>>>> 'integrated'
>>>>> with the geronimo/* commands. Looks like the JMX connection is not
>>>>> being shared between these groups of commands. We should be
>>>>> able to
>>>>> fix that. Please open a bug. Also, I just noticed that if an user
>>>>> changes the default user/password the geronimo/start-server
>>>>> command
>>>>> might fail with an error.
>>>>>
>>>>> Jarek
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> I just opened a jira for that original issue I mentioned.
>>>> https://issues.apache.org/jira/browse/GERONIMO-3869
>>>>
>>>> I'm not sure I understand that second issue you mentioned.
>>>
>>> The start-server command has hardcoded username/password combination
>>> and it cannot be specified on the command line. So if the
>>> password is
>>> changed and if you start the server let's say with:
>>>
>>> geronimo/start-server --background --timeout 60
>>>
>>> You will see something like:
>>>
>>> .....
>>> Geronimo Application Server started
>>> <after <60 seconds>
>>> ERROR Exception: Failed to start: Geronimo Server
>>>
>>> Even though the server started up fine but then becuase of the
>>> exception it will be killed.
>>>
>>> Jarek
>>
>>