Our first step is probably to deprecate it. We have some gfsh commands that
have deprecated info in the help (search for deprecated in CliStrings.java)
mostly for options we want to remove.
On Mon, Dec 30, 2019 at 9:37 AM Jinmei Liao wrote:
> If we can remove these support, I would like this app
If we can remove these support, I would like this approach too. Current
implementation has too many inconsistencies.
On Mon, Dec 30, 2019 at 9:34 AM Kirk Lund wrote:
> My vote is for #2 in Jinmei's proposal with the following correction:
>
> After removing --host/--port, you still have two ways
My vote is for #2 in Jinmei's proposal with the following correction:
After removing --host/--port, you still have two ways to get "status
locator":
a) Use --dir option:
gfsh>status locator --dir=/locator-dir
b) Use connect command first:
gfsh>connect locator
gfsh>status locator --name=locato
Long before we open-sourced as Geode, GemFire engineering planned to remove
support for:
gfsh>status locator --host=fooish --port=10334
The reasoning at the time was (1) this method for getting details about the
locator was wide open (security hole), and (2) it's inconsistent with
"status server"
So, looks like need to do either one of the following:
1. add --security-property-file option for the user to specify the ssl
connection properties
2. remove --host/--port combination and remove the capability to report the
status of the cluster configuration, this would only allow "status locator"
I think Jinmei is also referring to the situation where you might *not* already
be connected but want to execute something like this:
gfsh>status locator --host=fooish --port=10334
In this case it would fail as well. Seems like we'd either need to remove
those options so you *always* need to 'co
I like the approach Jens is suggesting, seems intuitive to me
On Thu, Dec 19, 2019 at 6:31 PM Jens Deppe wrote:
> So it seems that the situation is something like this where I'm able to
> make the initial connection but then retrieving status fails:
>
> gfsh>connect --security-properties-file=..
that's a solution too. but since "status locator" can point to any locator
that's running, it may not be the one that the current gfsh is connected to.
On Thu, Dec 19, 2019 at 6:31 PM Jens Deppe wrote:
> So it seems that the situation is something like this where I'm able to
> make the initial c
So it seems that the situation is something like this where I'm able to
make the initial connection but then retrieving status fails:
gfsh>connect --security-properties-file=../security.properties
gfsh>status locator --name=locator1
Server version response invalid: This could be the result of try
"status locator" command is broken on ssl enabled locators ever since we
fixed a bug that leaked the connection properties from one tcp socket
connection to another. Before that it would just magically work if we have
previously made a successfully tcp connection to that same locator, now we
are ei
10 matches
Mail list logo
