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 <jde...@pivotal.io> 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=../security.properties > > gfsh>status locator --name=locator1 > Server version response invalid: This could be the result of trying to > connect a non-SSL-enabled client to an SSL-enabled locator. > > > It would seem very weird if I have to provide additional connection params > to the 'status' command if I've already provided them as part of the > 'connect'. Could we not stash the connection properties (in the Gfsh > instance object) for subsequent usage? > > --Jens > > On Wed, Dec 18, 2019 at 9:04 AM Jinmei Liao <jil...@pivotal.io> wrote: > > > "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 either required to find a way to specify the ssl properties when > > running the `status locator` command or change what we want to report > back > > to the user. > > > > Here is what's happening now when we issue the command: > > > > 1. it needs to retrieve two sets of info from locator: general info > like > > (pid, working dir, status, jvm args etc) and whether cluster > > configuration > > service is running or not. > > 2. when locator’s ssl is on, the retrieval of the cluster > configuration > > info will always fail since it’s using a tcp connection to get that > info > > and we currently don’t have the ssl security properties to connect. > > 3. when locator’s ssl is on, the retrieval of the general info will > > mostly succeed except when user is only providing a host and port, > > there we > > would also need the ssl security properties in order to create an ssl > > socket. > > > > > > So we wither need to add an option for user to specify a > > `--security-properties-file` option to include all the ssl connection > > properties or change the behavior not to report cluster config status or > > not allowing host/port combination. (I am not here long enough to > > understand what users would use this command for, so this is just a > random > > suggestions). > > > > Comments/thoughts? > > > > -- > > Cheers > > > > Jinmei > > > -- Cheers Jinmei
