I like the approach Jens is suggesting, seems intuitive to me 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 > > >
