d that too. It would be nice to have those other commands
>> NOT do these sort of things either. It is a change if behavior, but how
>> many users are using this behavior?
>>
>>
>>
>> Original Message
>> Subject: Re: behavior of "
Message --------
> Subject: Re: behavior of "connect" command when --use-ssl
> From: John Blum
> To: geode
> CC:
>
>
> Well, then `connect` will be inconsistent with other commands (e.g. `start
> locator`) at best.
>
> Geode is going to pick up the gfSecurity
Well, then `connect` will be inconsistent with other commands (e.g. `start
locator`) at best.
Geode is going to pick up the gfSecurity.properties file in your HOME
directory whether you want it to or not, and especially regardless of the
options given to either `start locator` or `start server` si
I don't have any problem of having all the "security" info in another
properties file, but the fact that it's still trying to load a property
file even if the command did not say so explicitly. I might have such a
file sitting in my home dir for some occasions, but I may not want to use
it in this
Historically, gfSecurity.properties is a companion to gemfire.properties in
which sensitive key/value pairs can be kept in. The log banner does not (or
did not) log any values in gfSecurity.properties. Users would also
typically protect gfSecurity.properties with tighter permissions than
gemfire.pr
I am looking at a behavior of Gfsh's connect command using ssl. I am not
sure whether it's a valid use case or just some side effect of spaghetti
code.
So if SSL is configured on locator, and we need to connect to it in Gfsh
gfsh>connect --security-properties-file=ssl.properties
this will try to l