[JBoss JIRA] (ISPN-5059) JGroups subsystem doesn't support Vault
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/ISPN-5059?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on ISPN-5059:
--------------------------------
If Infinispan replaces the value of {{store_password}} with the correct contents, then we're fine. However, if it passes that variable unchanged to JGroups, we get an incorrect value. I'm not aware of Infinispan doing variable substitution for JGroups XML files (perhaps JDG does that?)...
Tristan ?
> JGroups subsystem doesn't support Vault
> ---------------------------------------
>
> Key: ISPN-5059
> URL: https://issues.jboss.org/browse/ISPN-5059
> Project: Infinispan
> Issue Type: Bug
> Components: Security, Server
> Reporter: Vojtech Juranek
>
> JGroups subsystem doesn't support passwords encrypted in Vault. E.g. when running [EncryptProtocolIT|https://github.com/infinispan/infinispan/blob/master/se...] with following configuration:
> {noformat}
> <protocol type="ENCRYPT">
> <property name="key_store_name">${jboss.server.config.dir}/server_jceks.keystore</property>
> <property name="store_password">${VAULT::keystore::password::1}</property>
> <property name="alias">memcached</property>
> </protocol>
> {noformat}
> i.e. it uses Vault-encrypted password for keystore, it fails with:
> {noformat}
> groups.channel.clustered: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:74)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:309)
> at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:250)
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481)
> at org.jgroups.JChannel.init(JChannel.java:848)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87)
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69)
> {noformat}
> Vault record for {{keystore::password}} exists:
> {noformat}
> Task: Verify whether a secured attribute exists
> Enter Vault Block:keystore
> Enter Attribute Name:password
> A value exists for (keystore, password)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5061) Cross site state transfer - NPE on consumer site when backup cache is not present
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5061?page=com.atlassian.jira.plugin.... ]
Work on ISPN-5061 started by Pedro Ruivo.
-----------------------------------------
> Cross site state transfer - NPE on consumer site when backup cache is not present
> ---------------------------------------------------------------------------------
>
> Key: ISPN-5061
> URL: https://issues.jboss.org/browse/ISPN-5061
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.1.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
>
> NPE detected on consumer site after invoking push operation on producer site. Occurs when corresponding cache does not exist on consumer site (either with the same name as the main cache or specified via <backup-for> option).
> Configuration:
> 2 sites, BRN (main), LON (backup)
> Producer site CLI:
> Unable to pushState to 'LON'. org.infinispan.commons.CacheException: Problems invoking command.
> Consumer site log:
> 11:18:45,245 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (remote-thread--p3-t1) ISPN000071: Caught exception when handling command XSiteStateTransferControlCommand{control=START_RECEIVE, siteName='LON', statusOk=false, cacheName='lonCache'}: java.lang.NullPointerException
> at org.infinispan.xsite.BackupReceiverImpl.invokeRemotelyInLocalSite(BackupReceiverImpl.java:213) [infinispan-core.jar:7.1.0.Alpha1]
> at org.infinispan.xsite.BackupReceiverImpl.handleStateTransferControl(BackupReceiverImpl.java:90) [infinispan-core.jar:7.1.0.Alpha1]
> at org.infinispan.xsite.statetransfer.XSiteStateTransferControlCommand.performInLocalSite(XSiteStateTransferControlCommand.java:41) [infinispan-core.jar:7.1.0.Alpha1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$3.run(CommandAwareRpcDispatcher.java:252) [infinispan-core.jar:7.1.0.Alpha1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> 11:18:45,420 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (remote-thread--p3-t1) ISPN000071: Caught exception when handling command XSiteStateTransferControlCommand{control=FINISH_RECEIVE, siteName='LON', statusOk=false, cacheName='lonCache'}: java.lang.NullPointerException
> at org.infinispan.xsite.BackupReceiverImpl.invokeRemotelyInLocalSite(BackupReceiverImpl.java:213) [infinispan-core.jar:7.1.0.Alpha1]
> at org.infinispan.xsite.BackupReceiverImpl.handleStateTransferControl(BackupReceiverImpl.java:90) [infinispan-core.jar:7.1.0.Alpha1]
> at org.infinispan.xsite.statetransfer.XSiteStateTransferControlCommand.performInLocalSite(XSiteStateTransferControlCommand.java:41) [infinispan-core.jar:7.1.0.Alpha1]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$3.run(CommandAwareRpcDispatcher.java:252) [infinispan-core.jar:7.1.0.Alpha1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5062) Cross site state transfer - incorrect status of push operation
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5062?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5062:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3146
> Cross site state transfer - incorrect status of push operation
> ---------------------------------------------------------------
>
> Key: ISPN-5062
> URL: https://issues.jboss.org/browse/ISPN-5062
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.1.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.Beta1
>
>
> Status of push operation remains at value "CANCELLED" after the push operation was cancelled and reinvoked (even if state transfer is currently in progress) - "SENDING" value is expected. Otherwise works as expected (after the state transfer completes, status is switched to "OK").
> - Sites LON (lonCache) - main, BRN (brnCache) - backup
> Consider the following scenario:
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --cancelpush BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=OK
> Expected behavior:
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --cancelpush BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=SENDING
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=OK
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5062) Cross site state transfer - incorrect status of push operation
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5062?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5062:
------------------------------
Fix Version/s: 7.1.0.Beta1
> Cross site state transfer - incorrect status of push operation
> ---------------------------------------------------------------
>
> Key: ISPN-5062
> URL: https://issues.jboss.org/browse/ISPN-5062
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.1.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.Beta1
>
>
> Status of push operation remains at value "CANCELLED" after the push operation was cancelled and reinvoked (even if state transfer is currently in progress) - "SENDING" value is expected. Otherwise works as expected (after the state transfer completes, status is switched to "OK").
> - Sites LON (lonCache) - main, BRN (brnCache) - backup
> Consider the following scenario:
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --cancelpush BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=OK
> Expected behavior:
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --cancelpush BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=SENDING
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=OK
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5035) DeltaAware support for conditional operations
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5035?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5035:
------------------------------------
I believe if the cache is not transactional DeltaAware isn't atomic either, unless the applying the Delta is an idempotent operation (as is the case with AtomicHashMap). Incrementing a counter is definitely not an idempotent operation...
Can you expand a bit on how you expect {{cache.replace(key, deltaAwareExpectedValue, deltaAwareNewValue)}} to work?
> DeltaAware support for conditional operations
> ---------------------------------------------
>
> Key: ISPN-5035
> URL: https://issues.jboss.org/browse/ISPN-5035
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Radim Vansa
>
> Current delta-aware approach is implemented only in PutKeyValueCommand and ApplyDeltaCommand. This implementation does not allow to execute conditional delta-aware commands - or rather it does not allow to return any kind of value (the condition itself can be implemented inside the delta).
> One use-case when this would be required is equivalent of AtomicLong.getAndIncrement(). Currently we can implement this using
> {code}
> Long previous;
> do {
> previous = cache.get(key);
> } while (cache.replace(key, previous, previous + 1);
> {code}
> which requires at least two RPCs. With more generic interface, such as JCache's EntryProcessor this could be implemented using single RPC.
> (so, this JIRA is basically a request to native support for EntryProcessor)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5048) Relocate some imported packages in uberjars and remove any javax.* classes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5048:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1170663|https://bugzilla.redhat.com/show_bug.cgi?id=1170663] from NEW to ASSIGNED
> Relocate some imported packages in uberjars and remove any javax.* classes
> --------------------------------------------------------------------------
>
> Key: ISPN-5048
> URL: https://issues.jboss.org/browse/ISPN-5048
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 7.0.2.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Final, 7.0.3.Final
>
>
> There is a readme in the jar for infinispan-embedded-query which states: "Copyright (c) 2008, 2009 Sun Microsystems, Oracle Corporation. All rights reserved."
> In /META-INF there are notices claiming that all of this is licensed as ASL2 which is not correct.
> we also include things like javax.persistence and javax.servlet, those are going to cause trouble for sure as I don't think it's reasonable to expect the users to not have duplicates of such things in their classpath.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5059) JGroups subsystem doesn't support Vault
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-5059?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-5059:
---------------------------------------
Well, but it should be a valid variable in ISPN server (and therefore bug logged for ISPN, not JGroups). It's also stated in [JGRP-1721|https://issues.jboss.org/browse/JGRP-1721?focusedCommentId=1282...] by [~NadirX], that Vault is supported.
I never dig into Vault if double colons can be changed to some other separator, but up to my current knowledge, double colons are required by Vault.
> JGroups subsystem doesn't support Vault
> ---------------------------------------
>
> Key: ISPN-5059
> URL: https://issues.jboss.org/browse/ISPN-5059
> Project: Infinispan
> Issue Type: Bug
> Components: Security, Server
> Reporter: Vojtech Juranek
>
> JGroups subsystem doesn't support passwords encrypted in Vault. E.g. when running [EncryptProtocolIT|https://github.com/infinispan/infinispan/blob/master/se...] with following configuration:
> {noformat}
> <protocol type="ENCRYPT">
> <property name="key_store_name">${jboss.server.config.dir}/server_jceks.keystore</property>
> <property name="store_password">${VAULT::keystore::password::1}</property>
> <property name="alias">memcached</property>
> </protocol>
> {noformat}
> i.e. it uses Vault-encrypted password for keystore, it fails with:
> {noformat}
> groups.channel.clustered: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:74)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:309)
> at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:250)
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481)
> at org.jgroups.JChannel.init(JChannel.java:848)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87)
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69)
> {noformat}
> Vault record for {{keystore::password}} exists:
> {noformat}
> Task: Verify whether a secured attribute exists
> Enter Vault Block:keystore
> Enter Attribute Name:password
> A value exists for (keystore, password)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months