[DISCUSS] RFC: New option for serial gw sender dispatcher threads start

[Alberto Bustamante Reyes]

Hi Geode community,

I have posted on the wiki a new RFC about implementing a new option for serial 
gateway sender creation related with how the dispatcher threads are started. 
This option will be used only when gateway receivers are configured to share 
same host and port. This configuration was already discussed on a previous RFC.

Please send your comments by Thursday 28th May.

https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start

Thanks,

Alberto B.

Re: [PROPOSAL] port GEODE-8144 changes to 1.13

[Bruce Schuchardt]

Yes, for sure it won't be backported until its gone through the build pipeline 
and is green.  Do you think I should withdraw this proposal until that process 
completes?

On 5/22/20, 2:27 PM, "Owen Nichols"  wrote:

In general, proposals to backport are more likely to get votes when the fix 
is already on develop and has been through some testing, especially as 
support/1.13 is (hopefully) getting close to RC1.  We’ve already seen several 
reverts on the support branch due to hasty backporting...

I’d love to see this fix make it into 1.13 and will be happy to add my 
endorsement first thing next week assuming it gets into develop before the 
weekend.

> On May 22, 2020, at 1:39 PM, Bruce Schuchardt  
wrote:
> 
> Sorry about the weird link - this is PR 5131
> 
> 
> 
> 
> On 5/22/20, 1:33 PM, "Bruce Schuchardt"  wrote:
> 
>I’ve been asked to propose backporting these changes to the 1.13 
branch.  This is a security issue – endpoint verification in servers is 
currently broken.  That is, if you enable it you’re unable to start up a 
cluster.
> 
> 
> 
>Endpoint verification requires the server-side of a tcp/ip connection 
to present a certificate that identifies the server by hostname.  The client 
then checks that hostname against what it expects as part of the TLS (“SSL”) 
handshake.
> 
> 
> 
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5131data=02%7C01%7Cbruces%40vmware.com%7C2af7dd5e1f6f4d31fd5708d7fe96de67%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637257796239130863sdata=G2PgcFaI8p%2F9tN1MXKRt%2FSBPdDBZRkJV2Faj7ygDFSY%3Dreserved=0
> 
> 
> 
> 
> 
> 

Re: [PROPOSAL] port GEODE-8144 changes to 1.13

[Owen Nichols]

In general, proposals to backport are more likely to get votes when the fix is 
already on develop and has been through some testing, especially as 
support/1.13 is (hopefully) getting close to RC1.  We’ve already seen several 
reverts on the support branch due to hasty backporting...

I’d love to see this fix make it into 1.13 and will be happy to add my 
endorsement first thing next week assuming it gets into develop before the 
weekend.

> On May 22, 2020, at 1:39 PM, Bruce Schuchardt  wrote:
> 
> Sorry about the weird link - this is PR 5131
> 
> 
> 
> 
> On 5/22/20, 1:33 PM, "Bruce Schuchardt"  wrote:
> 
>I’ve been asked to propose backporting these changes to the 1.13 branch.  
> This is a security issue – endpoint verification in servers is currently 
> broken.  That is, if you enable it you’re unable to start up a cluster.
> 
> 
> 
>Endpoint verification requires the server-side of a tcp/ip connection to 
> present a certificate that identifies the server by hostname.  The client 
> then checks that hostname against what it expects as part of the TLS (“SSL”) 
> handshake.
> 
> 
> 
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5131data=02%7C01%7Cbruces%40vmware.com%7Cbdbbf0ecaf9049c974b908d7fe8f62b4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637257764107593299sdata=kSxTyXxzsavxBRD97eR8KM%2FNyuLV9XwFLun5NzLwxjs%3Dreserved=0
> 
> 
> 
> 
> 
> 

Re: [PROPOSAL] port GEODE-8144 changes to 1.13

[Bruce Schuchardt]

Sorry about the weird link - this is PR 5131




On 5/22/20, 1:33 PM, "Bruce Schuchardt"  wrote:

I’ve been asked to propose backporting these changes to the 1.13 branch.  
This is a security issue – endpoint verification in servers is currently 
broken.  That is, if you enable it you’re unable to start up a cluster.

 

Endpoint verification requires the server-side of a tcp/ip connection to 
present a certificate that identifies the server by hostname.  The client then 
checks that hostname against what it expects as part of the TLS (“SSL”) 
handshake.

 


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F5131data=02%7C01%7Cbruces%40vmware.com%7Cbdbbf0ecaf9049c974b908d7fe8f62b4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637257764107593299sdata=kSxTyXxzsavxBRD97eR8KM%2FNyuLV9XwFLun5NzLwxjs%3Dreserved=0

 

[PROPOSAL] port GEODE-8144 changes to 1.13

[Bruce Schuchardt]

I’ve been asked to propose backporting these changes to the 1.13 branch.  This 
is a security issue – endpoint verification in servers is currently broken.  
That is, if you enable it you’re unable to start up a cluster.

 

Endpoint verification requires the server-side of a tcp/ip connection to 
present a certificate that identifies the server by hostname.  The client then 
checks that hostname against what it expects as part of the TLS (“SSL”) 
handshake.

 

https://github.com/apache/geode/pull/5131

 

Re: Questions about patch releases and changes in serialization versions / messages

[Alberto Gomez]

Thanks for the quick answer, Owen.

Is this information published anywhere?

Cheers,

-Alberto G.

From: Owen Nichols 
Sent: Friday, May 22, 2020 5:56 PM
To: dev@geode.apache.org 
Subject: Re: Questions about patch releases and changes in serialization 
versions / messages

Serialization changes are only permitted in new minor releases (x.y.0).

> On May 22, 2020, at 4:40 AM, Alberto Gomez  wrote:
>
> Hi,
>
> The recently approved RFC about patch releases 
> (https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases) 
> says the following about what changes should and should not be backported to 
> a support branch:
>
> What changes should be back ported to a support branch?
>
> The community will exercise good judgement in the same way that important 
> changes are cherry-picked onto release branches prior to shipping a new 
> release.  Fixes related to data safety and consistency, cluster stability, or 
> API behaviors are good candidates to be considered.
>
> What changes should NOT be back ported to a support branch?
>
> New features, refactoring changes, or less important and non-critical bug 
> fixes.  Of course, you are always free to advocate within the community and 
> state your case!
>
> This raises a question on whether changes that fall on the first category 
> according to the above guidelines but also contain, changes in Data 
> Serialization (for example adding/removing fields from a DataSerializable 
> class) would still be allowed to be backported to a support branch.
>
> If the answer is affirmative, I wonder if/how the backward compatibility 
> could be guaranteed between a newer release and a patch release in the case 
> that both included the same Data Serialization change.
>
> Example:
> Imagine that 1.13.0 includes a change that adds a new field to a 
> DataSerializable class. In order to support backward compatibility, the 
> change will include the implementation of the corresponding 
> fromDataPre_1_13_0 and toDataPre_1_13_0 methods.
>
> Now, let's assume that this change is decided to be backported to previous 
> patch releases, for example 1.12.0.1. The cherry-picked commit will need to 
> be changed so that the above methods are renamed to fromDataPre_1_12_0_1 and 
> toDataPre_1_12_0_1.
>
> Problems could arise nevertheless when a Geode system on version 1.12.0.1 
> (patch release) is upgraded to 1.13.0. Both Geode versions will think that 
> the new field was added in their version. As a result, when a peer on version 
> 1.13.0 sends an instance of the modified class to a peer on version 1.12.0.1, 
> it will not send the new field but, the peer on version 1.12.0.1 will expect 
> it. If, on the other hand, a peer on version 1.12.0.1 sends an instance of 
> the modified class to a peer on version 1.13.0, the peer on version 1.13.0 
> will not read the new field even if it was sent by the peer on 1.12.0.1.
>
> Is there anything I am missing in my reasoning?
> Has this case been contemplated?
> Should these changes be prevented from support branches to avoid these 
> problems?
>
> Thanks in advance,
>
> -Alberto G.

Re: Questions about patch releases and changes in serialization versions / messages

[Owen Nichols]

Serialization changes are only permitted in new minor releases (x.y.0).  

> On May 22, 2020, at 4:40 AM, Alberto Gomez  wrote:
> 
> Hi,
> 
> The recently approved RFC about patch releases 
> (https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases) 
> says the following about what changes should and should not be backported to 
> a support branch:
> 
> What changes should be back ported to a support branch?
> 
> The community will exercise good judgement in the same way that important 
> changes are cherry-picked onto release branches prior to shipping a new 
> release.  Fixes related to data safety and consistency, cluster stability, or 
> API behaviors are good candidates to be considered.
> 
> What changes should NOT be back ported to a support branch?
> 
> New features, refactoring changes, or less important and non-critical bug 
> fixes.  Of course, you are always free to advocate within the community and 
> state your case!
> 
> This raises a question on whether changes that fall on the first category 
> according to the above guidelines but also contain, changes in Data 
> Serialization (for example adding/removing fields from a DataSerializable 
> class) would still be allowed to be backported to a support branch.
> 
> If the answer is affirmative, I wonder if/how the backward compatibility 
> could be guaranteed between a newer release and a patch release in the case 
> that both included the same Data Serialization change.
> 
> Example:
> Imagine that 1.13.0 includes a change that adds a new field to a 
> DataSerializable class. In order to support backward compatibility, the 
> change will include the implementation of the corresponding 
> fromDataPre_1_13_0 and toDataPre_1_13_0 methods.
> 
> Now, let's assume that this change is decided to be backported to previous 
> patch releases, for example 1.12.0.1. The cherry-picked commit will need to 
> be changed so that the above methods are renamed to fromDataPre_1_12_0_1 and 
> toDataPre_1_12_0_1.
> 
> Problems could arise nevertheless when a Geode system on version 1.12.0.1 
> (patch release) is upgraded to 1.13.0. Both Geode versions will think that 
> the new field was added in their version. As a result, when a peer on version 
> 1.13.0 sends an instance of the modified class to a peer on version 1.12.0.1, 
> it will not send the new field but, the peer on version 1.12.0.1 will expect 
> it. If, on the other hand, a peer on version 1.12.0.1 sends an instance of 
> the modified class to a peer on version 1.13.0, the peer on version 1.13.0 
> will not read the new field even if it was sent by the peer on 1.12.0.1.
> 
> Is there anything I am missing in my reasoning?
> Has this case been contemplated?
> Should these changes be prevented from support branches to avoid these 
> problems?
> 
> Thanks in advance,
> 
> -Alberto G.

Certificate based authorization - CN authorization in jmx

[Mario Kevo]

Hi geode-dev,

We are working on implementing a new feature regarding to this 
RFC.

The main idea is to combine the TLS and access control features, but to use the 
certificate subject common name for access control authentication/authorization 
instead of user credentials.
We need to get client certificate on the server side to extract common name 
from it. The problem is that gfsh client connects towards to jmx using RMI TCP 
connections. We have tried many things to get client certificate from 
established RMI Connection but unfortunately without success.

Did anyone have the similar problem and able to extract certificate from RMI 
Connection after TLS handshake has been completed?

BR,
Mario

Questions about patch releases and changes in serialization versions / messages

[Alberto Gomez]

Hi,

The recently approved RFC about patch releases 
(https://cwiki.apache.org/confluence/display/GEODE/Shipping+patch+releases) 
says the following about what changes should and should not be backported to a 
support branch:

What changes should be back ported to a support branch?

The community will exercise good judgement in the same way that important 
changes are cherry-picked onto release branches prior to shipping a new 
release.  Fixes related to data safety and consistency, cluster stability, or 
API behaviors are good candidates to be considered.

What changes should NOT be back ported to a support branch?

New features, refactoring changes, or less important and non-critical bug 
fixes.  Of course, you are always free to advocate within the community and 
state your case!

This raises a question on whether changes that fall on the first category 
according to the above guidelines but also contain, changes in Data 
Serialization (for example adding/removing fields from a DataSerializable 
class) would still be allowed to be backported to a support branch.

If the answer is affirmative, I wonder if/how the backward compatibility could 
be guaranteed between a newer release and a patch release in the case that both 
included the same Data Serialization change.

Example:
Imagine that 1.13.0 includes a change that adds a new field to a 
DataSerializable class. In order to support backward compatibility, the change 
will include the implementation of the corresponding fromDataPre_1_13_0 and 
toDataPre_1_13_0 methods.

Now, let's assume that this change is decided to be backported to previous 
patch releases, for example 1.12.0.1. The cherry-picked commit will need to be 
changed so that the above methods are renamed to fromDataPre_1_12_0_1 and 
toDataPre_1_12_0_1.

Problems could arise nevertheless when a Geode system on version 1.12.0.1 
(patch release) is upgraded to 1.13.0. Both Geode versions will think that the 
new field was added in their version. As a result, when a peer on version 
1.13.0 sends an instance of the modified class to a peer on version 1.12.0.1, 
it will not send the new field but, the peer on version 1.12.0.1 will expect 
it. If, on the other hand, a peer on version 1.12.0.1 sends an instance of the 
modified class to a peer on version 1.13.0, the peer on version 1.13.0 will not 
read the new field even if it was sent by the peer on 1.12.0.1.

Is there anything I am missing in my reasoning?
Has this case been contemplated?
Should these changes be prevented from support branches to avoid these problems?

Thanks in advance,

-Alberto G.

Re: Creating Regions Dynamically

[Ju@N]

Hello there,

The regions manually created using the Geode API are not persisted to
the *cluster-configuration-service
[1]*, that's basically the reason why you don't see them after the server
is restarted. It's possible to dig into the source code and persist the
changes yourself (have a look at the *CreateRegionCommand [2]* class), but
it's also something I wouldn't recommend... Instead of that, I'd suggest to
use the *Geode SHell [2]* to manage your regions directly.
Hope this helps.
Best regards.

[1]:
https://geode.apache.org/docs/guide/112/configuring/cluster_config/gfsh_persist.html
[2]:
https://github.com/apache/geode/blob/develop/geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/commands/CreateRegionCommand.java
[3]:
https://geode.apache.org/docs/guide/112/tools_modules/gfsh/chapter_overview.html

On Fri, 22 May 2020 at 04:42, 18911098...@163.com <18911098...@163.com>
wrote:

> dear:
>  Dynamically  Create Region Demo ，When Geode Server Reboot  ,Lost
> Region   instance
>
> https://geode.apache.org/docs/guide/112/developing/region_options/dynamic_region_creation.html
>
>  I don't know why?   Hope to help me, thanks!
>
>
>
> 18911098...@163.com
>


-- 
Ju@N