Stale installer/pom.xml
Hi, The installer modules are listed in the main pom but there's also an installer/pom.xml, can we remove it? -Bertrand
Re: TopologyConnectorServlet
Hi Ian,
+1
I like the idea of making an API out of this. One thing to remember is
that this API would be part of discovery.impl rather than discovery.api -
since the discovery.api does not make any assumptions on how
instances/clusters discover each other. Nevertheless I think it's a good
idea.
Additionally, I wonder if we could also include the possibility of
encrypting/decrypting the payload that discovery.impl sends around via the
topology connectors? It could be a separate service - eg
DiscoveryPayloadHandler - and provide methods to encrypt and
decrypt/verify.
Cheers,
Stefan
On 10/8/13 7:40 PM, Ian Boston i...@tfd.co.uk wrote:
Hi,
The whitelist configuration in this servlet is causing some problems
where the contents of the whitelist is potentially large and changing,
since it requires constant re-configuration.
Would it be possible to have a API service that is consulted if
present to check if the request is allowed. For those that want to use
the service they would configure the whitelist to reject everything
while the service was not present so avoid startup issues.
eg
+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
+ private WhiteListProvider whiteListProvider;
/** Checks if the provided request's remote server is whitelisted **/
private boolean isWhitelisted(final SlingHttpServletRequest request) {
+ if (whiteListProvider != null) {
+ whiteListProvider.isWhitelisted(request);
+}
if (whitelist.contains(request.getRemoteAddr())) {
return true;
} else if (whitelist.contains(request.getRemoteHost())) {
return true;
}
logger.info(isWhitelisted: rejecting + request.getRemoteAddr()
+ , + request.getRemoteHost());
return false;
}
and in the API, presumably discovery api.
public interface WhiteListProvider {
private boolean isWhitelisted(HttpServletRequest request);
}
Best Regards
Ian
[jira] [Created] (SLING-3154) Add Topology Message Verification to the Discovery service.
Ian Boston created SLING-3154: - Summary: Add Topology Message Verification to the Discovery service. Key: SLING-3154 URL: https://issues.apache.org/jira/browse/SLING-3154 Project: Sling Issue Type: Improvement Components: General Affects Versions: Discovery Impl 1.0.0 Reporter: Ian Boston Assignee: Ian Boston Fix For: Discovery Impl 1.0.2 The discovery service provides support for whitelisting sources of topology information, but in a cluster where the topology this creates a re-configuration load of order M*(n*(n-1)) where n is the number of nodes in the topology and M is the number of changes. That load rises rapidly as the number of changes and/or nodes increases. To address this there are 2 proposals. 1. To provide an SPI exported from the Discovery Impl bundle that allows implementors to implement whitelisting based on the request. This will need to support creating the request and validating the request. 2. Embed functionality within the Discovery Impl bundle that supports validation and encryption of topology requests. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: TopologyConnectorServlet
On 9 October 2013 09:16, Stefan Egli e...@adobe.com wrote:
Hi Ian,
+1
I like the idea of making an API out of this. One thing to remember is
that this API would be part of discovery.impl rather than discovery.api -
since the discovery.api does not make any assumptions on how
instances/clusters discover each other. Nevertheless I think it's a good
idea.
Ok, thats probably easier if its Ok for the Discovery Impl to export a package.
I forgot 1 thing, there will need to be support for creating the
aspects of the request that make it trusted, as well as white listing
it.
Additionally, I wonder if we could also include the possibility of
encrypting/decrypting the payload that discovery.impl sends around via the
topology connectors? It could be a separate service - eg
DiscoveryPayloadHandler - and provide methods to encrypt and
decrypt/verify.
That would be a larger patch, but would also work. If its going to
cover all bases, does it need to be outside the Discovery impl ?
I've started a jira for this [1]
Best Regards
Ian
1 https://issues.apache.org/jira/browse/SLING-3154
Cheers,
Stefan
On 10/8/13 7:40 PM, Ian Boston i...@tfd.co.uk wrote:
Hi,
The whitelist configuration in this servlet is causing some problems
where the contents of the whitelist is potentially large and changing,
since it requires constant re-configuration.
Would it be possible to have a API service that is consulted if
present to check if the request is allowed. For those that want to use
the service they would configure the whitelist to reject everything
while the service was not present so avoid startup issues.
eg
+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
+ private WhiteListProvider whiteListProvider;
/** Checks if the provided request's remote server is whitelisted **/
private boolean isWhitelisted(final SlingHttpServletRequest request) {
+ if (whiteListProvider != null) {
+ whiteListProvider.isWhitelisted(request);
+}
if (whitelist.contains(request.getRemoteAddr())) {
return true;
} else if (whitelist.contains(request.getRemoteHost())) {
return true;
}
logger.info(isWhitelisted: rejecting + request.getRemoteAddr()
+ , + request.getRemoteHost());
return false;
}
and in the API, presumably discovery api.
public interface WhiteListProvider {
private boolean isWhitelisted(HttpServletRequest request);
}
Best Regards
Ian
[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.
[
https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790170#comment-13790170
]
Stefan Egli commented on SLING-3154:
I think we might be able to cover both aspects (the whitelist, and the
encrypt/decrypt) with one API - basically provide one hook to 'pack' a payload
for posting and one for 'unpacking' (and thus verifying) upon reception. Eg the
API could be along the following lines:
public interface DiscoveryPayloadHandler {
public RequestEntity pack(String json);
public String unpack(SlingHttpServletRequest request) throws
RejectException;
}
Whereas pack() would be used in the TopologyConnectorClient before posting the
request, and unpack() would be used in the TopologyConnectorServlet when
handling the PUT/DELETE requests. Throwing of the RejectException would imply
ignoring/rejecting the request/announcement.
pack/unpack could be doing encrypt/decrypt/verify - but they could also do
things like gizp for example.
Add Topology Message Verification to the Discovery service.
---
Key: SLING-3154
URL: https://issues.apache.org/jira/browse/SLING-3154
Project: Sling
Issue Type: Improvement
Components: General
Affects Versions: Discovery Impl 1.0.0
Reporter: Ian Boston
Assignee: Ian Boston
Fix For: Discovery Impl 1.0.2
The discovery service provides support for whitelisting sources of topology
information, but in a cluster where the topology this creates a
re-configuration load of order M*(n*(n-1)) where n is the number of nodes in
the topology and M is the number of changes. That load rises rapidly as the
number of changes and/or nodes increases.
To address this there are 2 proposals.
1. To provide an SPI exported from the Discovery Impl bundle that allows
implementors to implement whitelisting based on the request. This will need
to support creating the request and validating the request.
2. Embed functionality within the Discovery Impl bundle that supports
validation and encryption of topology requests.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (SLING-3154) Add Topology Message Verification to the Discovery service.
[
https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790170#comment-13790170
]
Stefan Egli edited comment on SLING-3154 at 10/9/13 9:03 AM:
-
I think we might be able to cover both aspects (the whitelist, and the
encrypt/decrypt) with one API - basically provide one hook to 'pack' a payload
for posting and one for 'unpacking' (and thus verifying) upon reception. Eg the
API could be along the following lines:
{code:java}
public interface DiscoveryPayloadHandler {
public RequestEntity pack(String json);
public String unpack(SlingHttpServletRequest request) throws
RejectException;
}
{code}
Whereas pack() would be used in the TopologyConnectorClient before posting the
request, and unpack() would be used in the TopologyConnectorServlet when
handling the PUT/DELETE requests. Throwing of the RejectException would imply
ignoring/rejecting the request/announcement.
pack/unpack could be doing encrypt/decrypt/verify - but they could also do
things like gizp for example.
was (Author: egli):
I think we might be able to cover both aspects (the whitelist, and the
encrypt/decrypt) with one API - basically provide one hook to 'pack' a payload
for posting and one for 'unpacking' (and thus verifying) upon reception. Eg the
API could be along the following lines:
public interface DiscoveryPayloadHandler {
public RequestEntity pack(String json);
public String unpack(SlingHttpServletRequest request) throws
RejectException;
}
Whereas pack() would be used in the TopologyConnectorClient before posting the
request, and unpack() would be used in the TopologyConnectorServlet when
handling the PUT/DELETE requests. Throwing of the RejectException would imply
ignoring/rejecting the request/announcement.
pack/unpack could be doing encrypt/decrypt/verify - but they could also do
things like gizp for example.
Add Topology Message Verification to the Discovery service.
---
Key: SLING-3154
URL: https://issues.apache.org/jira/browse/SLING-3154
Project: Sling
Issue Type: Improvement
Components: General
Affects Versions: Discovery Impl 1.0.0
Reporter: Ian Boston
Assignee: Ian Boston
Fix For: Discovery Impl 1.0.2
The discovery service provides support for whitelisting sources of topology
information, but in a cluster where the topology this creates a
re-configuration load of order M*(n*(n-1)) where n is the number of nodes in
the topology and M is the number of changes. That load rises rapidly as the
number of changes and/or nodes increases.
To address this there are 2 proposals.
1. To provide an SPI exported from the Discovery Impl bundle that allows
implementors to implement whitelisting based on the request. This will need
to support creating the request and validating the request.
2. Embed functionality within the Discovery Impl bundle that supports
validation and encryption of topology requests.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (SLING-1803) add coverage reporting of integration tests
[ https://issues.apache.org/jira/browse/SLING-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790171#comment-13790171 ] Bertrand Delacretaz commented on SLING-1803: For now I have added a new jacoco-report profile to the Sling parent pom, http://svn.apache.org/r1530538 With this, a build that's run with -Pjacoco-report and includes tests produces a test coverage report at target/site/jacoco/index.html add coverage reporting of integration tests --- Key: SLING-1803 URL: https://issues.apache.org/jira/browse/SLING-1803 Project: Sling Issue Type: New Feature Components: Launchpad Reporter: Justin Edelson Assignee: Bertrand Delacretaz Attachments: integration-deploys-jacoco-exec.patch, jacoco-pom.patch, SLING-1803-1053340.patch I've tried both emma and clover. Looks like emma is the right choice as it is a little more flexible in terms of breaking apart the instrumentation from the test execution. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SLING-3155) Switch launchpad between Jackrabbit and Oak based on run modes
Bertrand Delacretaz created SLING-3155: -- Summary: Switch launchpad between Jackrabbit and Oak based on run modes Key: SLING-3155 URL: https://issues.apache.org/jira/browse/SLING-3155 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz We need this to run our integration tests on both Jackrabbit and Oak. Using -Dsling.run.modes=jackrabbit (or oak) on the first startup of the launchpad runnable jar will switch. These run modes need to be set to be mutually exclusive and considered only on the first startup, we don't support switching later. We'll need to support upgrading a Jackrabbit repository to Oak but that's a different issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SLING-3156) Add bundles support to Launchpad installer
Bertrand Delacretaz created SLING-3156: -- Summary: Add bundles support to Launchpad installer Key: SLING-3156 URL: https://issues.apache.org/jira/browse/SLING-3156 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Installer 1.2.0 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz The launchpad installer currently supports only configurations, but for SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (SLING-3157) Launchpad bootstrap: prepare bundles for launchpad installer
Bertrand Delacretaz created SLING-3157: -- Summary: Launchpad bootstrap: prepare bundles for launchpad installer Key: SLING-3157 URL: https://issues.apache.org/jira/browse/SLING-3157 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Once SLING-3156 is implemented we'll need to modify the launchpad bootstrap code to copy the runmode-dependent bundles to where the launchpad installer expects to find them. Currently, bundles found in the launchpad jar under paths like resources/bundles.foo/5 (for runmode foo and run level 5) are ignored by the bootstrap installer, we might just need to copy those to the right filesystem folder. -- This message was sent by Atlassian JIRA (v6.1#6144)
Jenkins build is back to normal : sling-trunk-1.7 #322
See https://builds.apache.org/job/sling-trunk-1.7/322/changes
Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling SLF4J Implementation (Logback) #322
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.commons.log/322/
Jenkins build is back to normal : sling-trunk-1.6 #1953
See https://builds.apache.org/job/sling-trunk-1.6/1953/changes
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Resource-Based Discovery Service #1953
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.discovery.impl/1953/
Jenkins build is back to normal : sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1953
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing-war/1953/
Re: TopologyConnectorServlet
On 10/9/13 10:34 AM, Ian Boston i...@tfd.co.uk wrote:
On 9 October 2013 09:16, Stefan Egli e...@adobe.com wrote:
Hi Ian,
+1
I like the idea of making an API out of this. One thing to remember is
that this API would be part of discovery.impl rather than discovery.api
-
since the discovery.api does not make any assumptions on how
instances/clusters discover each other. Nevertheless I think it's a good
idea.
Ok, thats probably easier if its Ok for the Discovery Impl to export a
package.
I forgot 1 thing, there will need to be support for creating the
aspects of the request that make it trusted, as well as white listing
it.
I added a suggestion for the API to SLING-3154 - do you see additional
properties (to the plain request object) needed to decide if a request can
be trusted?
Additionally, I wonder if we could also include the possibility of
encrypting/decrypting the payload that discovery.impl sends around via
the
topology connectors? It could be a separate service - eg
DiscoveryPayloadHandler - and provide methods to encrypt and
decrypt/verify.
That would be a larger patch, but would also work. If its going to
cover all bases, does it need to be outside the Discovery impl ?
I see it as an optional thing, surely. But was thinking it would be a good
idea to make the API also support that case.
Cheers,
Stefan
I've started a jira for this [1]
Best Regards
Ian
1 https://issues.apache.org/jira/browse/SLING-3154
Cheers,
Stefan
On 10/8/13 7:40 PM, Ian Boston i...@tfd.co.uk wrote:
Hi,
The whitelist configuration in this servlet is causing some problems
where the contents of the whitelist is potentially large and changing,
since it requires constant re-configuration.
Would it be possible to have a API service that is consulted if
present to check if the request is allowed. For those that want to use
the service they would configure the whitelist to reject everything
while the service was not present so avoid startup issues.
eg
+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
+ private WhiteListProvider whiteListProvider;
/** Checks if the provided request's remote server is whitelisted
**/
private boolean isWhitelisted(final SlingHttpServletRequest
request) {
+ if (whiteListProvider != null) {
+ whiteListProvider.isWhitelisted(request);
+}
if (whitelist.contains(request.getRemoteAddr())) {
return true;
} else if (whitelist.contains(request.getRemoteHost())) {
return true;
}
logger.info(isWhitelisted: rejecting +
request.getRemoteAddr()
+ , + request.getRemoteHost());
return false;
}
and in the API, presumably discovery api.
public interface WhiteListProvider {
private boolean isWhitelisted(HttpServletRequest request);
}
Best Regards
Ian
Re: Stale installer/pom.xml
yepp, we once decided to directly references all modules from the root pom and get rid of intermediate reactor poms 2013/10/9 Bertrand Delacretaz bdelacre...@apache.org Hi, The installer modules are listed in the main pom but there's also an installer/pom.xml, can we remove it? -Bertrand -- Carsten Ziegeler cziege...@apache.org
Build failed in Jenkins: sling-trunk-1.7 #323
See https://builds.apache.org/job/sling-trunk-1.7/323/ -- [...truncated 320 lines...] Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:507) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) ... 14 more Caused by: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 33 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E204899: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: E204899: Cannot create new file '/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:748) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) ... 32 more Caused by: svn: E204899: REPORT request failed on '/repos/asf/!svn/vcc/default' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:407) ... 34 more Caused by: svn: E204899: Cannot create new file '/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126) at org.tmatesoft.svn.core.internal.wc.SVNFileUtil.createEmptyFile(SVNFileUtil.java:346) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14.createVersionedDirectory(SVNAdminArea14.java:1553) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory.doCreateVersionedDirectory(SVNAdminArea16Factory.java:30) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.createVersionedDirectory(SVNAdminAreaFactory.java:241) at org.tmatesoft.svn.core.internal.wc.SVNWCManager.ensureAdminAreaExists(SVNWCManager.java:428) at org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.addDir(SVNUpdateEditor.java:762) at org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.addDir(SVNCancellableEditor.java:84) at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVEditorHandler.startElement(DAVEditorHandler.java:326) at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.startElement(BasicDAVHandler.java:89) at
[jira] [Commented] (SLING-3157) Launchpad bootstrap: prepare bundles for launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790226#comment-13790226 ] Carsten Ziegeler commented on SLING-3157: - I think we don't need anything here, look at our Adobe projects where we have run mode dependent bundles and configurations and this is using plain Sling launchpad/launchpad plugin Launchpad bootstrap: prepare bundles for launchpad installer Key: SLING-3157 URL: https://issues.apache.org/jira/browse/SLING-3157 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Once SLING-3156 is implemented we'll need to modify the launchpad bootstrap code to copy the runmode-dependent bundles to where the launchpad installer expects to find them. Currently, bundles found in the launchpad jar under paths like resources/bundles.foo/5 (for runmode foo and run level 5) are ignored by the bootstrap installer, we might just need to copy those to the right filesystem folder. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790229#comment-13790229 ] Carsten Ziegeler commented on SLING-3156: - We don't need to implement this, simply don't use the launchpad installer for these bundles and delegate them to the OSGi installer. This is just a tweak of configuration (we use this within Adobe) and everything works ootb Add bundles support to Launchpad installer -- Key: SLING-3156 URL: https://issues.apache.org/jira/browse/SLING-3156 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Installer 1.2.0 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz The launchpad installer currently supports only configurations, but for SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790230#comment-13790230 ] Carsten Ziegeler commented on SLING-3156: - Otherwise we would duplicate stuff already in the OSGi installer which is not worth the effort Add bundles support to Launchpad installer -- Key: SLING-3156 URL: https://issues.apache.org/jira/browse/SLING-3156 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Installer 1.2.0 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz The launchpad installer currently supports only configurations, but for SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790233#comment-13790233 ] Carsten Ziegeler commented on SLING-3156: - The startup bundles (OSGi installer, launchpad installer and one or two more) need to be specified with: startLevel level=boot in the bundle list - these bundles are the once which can't be run mode dependent. All bundles in real start levels including the default can use a run mode configuration in the bundle list. and then the maven launchpad plugin needs to be configured with bundlesDirectoryinstall/bundlesDirectory bootDirectorybundles/bootDirectory Et voila Add bundles support to Launchpad installer -- Key: SLING-3156 URL: https://issues.apache.org/jira/browse/SLING-3156 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Installer 1.2.0 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz The launchpad installer currently supports only configurations, but for SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: Configuration - Well Known Properties Question
Hi Dan, yes, I think changing the link to point to the sling.properties section is the right thing. For the configuration properties, I think we can completely drop sling.install and sling.install.bundles. We could explain org.apache.osgi.bundles - however although they are supported, Sling provides better mechanisms therefore I think we can leave this one out. And right, logging should be org.apache.sling.commons.log.*. Carsten 2013/10/8 Daniel Klco dk...@apache.org All, I am looking into migrating the Configuration page: http://sling.staging.apache.org/documentation/configuration.html The only remaining issue seems to be the links in the Well Known Properties section: http://sling.staging.apache.org/documentation/configuration.html#well-known-properties The page they link to is just a skeleton, should they link to the sling.properties section on the Launchpad page instead? http://sling.staging.apache.org/documentation/the-sling-engine/the-sling-launchpad.html#slingproperties Also, I can't seem to find any references to the last three properties: - sling.install.bundles - sling.install.n - org.apache.sling.osgi.log.* It seems like the have been changed as follows: sling.install.n - org.apache.osgi.bundles org.apache.sling.osgi.log.* - org.apache.sling.commons.log.* Does that sound right? Or am I missing something? Thanks, Dan -- Carsten Ziegeler cziege...@apache.org
[jira] [Commented] (SLING-3156) Add bundles support to Launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790276#comment-13790276 ] Bertrand Delacretaz commented on SLING-3156: Ok, I'll have a look - documenting these options at http://sling.apache.org/documentation/development/maven-launchpad-plugin.html wouldn't hurt. Add bundles support to Launchpad installer -- Key: SLING-3156 URL: https://issues.apache.org/jira/browse/SLING-3156 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Installer 1.2.0 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz The launchpad installer currently supports only configurations, but for SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: Stale installer/pom.xml
On Wed, Oct 9, 2013 at 12:09 PM, Carsten Ziegeler cziege...@apache.org wrote: ... we once decided to directly references all modules from the root pom and get rid of intermediate reactor poms... ok, I have removed to redundant installer/pom.xml -Bertrand
[jira] [Commented] (SLING-3143) CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members
[ https://issues.apache.org/jira/browse/SLING-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790299#comment-13790299 ] Antonio Sanso commented on SLING-3143: -- While I do not like too much this feature of having a special group configured via osgi that skips ACLs it seems that is a feature of Sling. I will attach a patch that would create those groups on demand (only for the tests). [~bdelacretaz] WDYT? CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members Key: SLING-3143 URL: https://issues.apache.org/jira/browse/SLING-3143 Project: Sling Issue Type: Bug Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3143-forceAdminSession.patch, SLING-3144-patch.txt CreateUserServlet.createUser detects if the current user is a member of the UserAdmin group (group name is configurable), and if that's the case considers the user as admin and uses its session to create a new user. This fails on Oak, our launchpad/integration-tests CreateUserTest fails. I'll attach a patch that works around the problem by forcing the use of an admin session in this case, but I'm not sure if it's the right thing to do, I'll discuss on the dev list. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Issue Comment Deleted] (SLING-3143) CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members
[ https://issues.apache.org/jira/browse/SLING-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso updated SLING-3143: - Comment: was deleted (was: While I do not like too much this feature of having a special group configured via osgi that skips ACLs it seems that is a feature of Sling. I will attach a patch that would create those groups on demand (only for the tests). [~bdelacretaz] WDYT?) CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members Key: SLING-3143 URL: https://issues.apache.org/jira/browse/SLING-3143 Project: Sling Issue Type: Bug Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3143-forceAdminSession.patch CreateUserServlet.createUser detects if the current user is a member of the UserAdmin group (group name is configurable), and if that's the case considers the user as admin and uses its session to create a new user. This fails on Oak, our launchpad/integration-tests CreateUserTest fails. I'll attach a patch that works around the problem by forcing the use of an admin session in this case, but I'm not sure if it's the right thing to do, I'll discuss on the dev list. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SLING-3144) UserAdmin and GroupAdmin groups are missing on our Oak setup
[ https://issues.apache.org/jira/browse/SLING-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso updated SLING-3144: - Attachment: SLING-3144-patch.txt UserAdmin and GroupAdmin groups are missing on our Oak setup Key: SLING-3144 URL: https://issues.apache.org/jira/browse/SLING-3144 Project: Sling Issue Type: Bug Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3144-patch.txt Some of my SLING-2788 integration tests (for example PrivilegesInfoTest) fail as the UserAdmin and GroupAdmin don't initially exist. In Jackrabbit those groups are apparently created by UserAccessControlProvider [1] - I'll ask the Oak team how to have the equivalent in Oak. As a workaround, creating those groups as follows allows a few more tests to pass - but for the final setup the groups need to be created with specific security-related parameters. curl -u admin:admin -F:name=GroupAdmin http://localhost:8080/system/userManager/group.create.html curl -u admin:admin -F:name=UserAdmin http://localhost:8080/system/userManager/group.create.html [1] http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/user/UserAccessControlProvider.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3144) UserAdmin and GroupAdmin groups are missing on our Oak setup
[ https://issues.apache.org/jira/browse/SLING-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790300#comment-13790300 ] Antonio Sanso commented on SLING-3144: -- While I do not like too much this feature of having a special group configured via osgi that skips ACLs it seems that is a feature of Sling. I will attach a patch that would create those groups on demand (only for the tests). Bertrand Delacretaz WDYT? UserAdmin and GroupAdmin groups are missing on our Oak setup Key: SLING-3144 URL: https://issues.apache.org/jira/browse/SLING-3144 Project: Sling Issue Type: Bug Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3144-patch.txt Some of my SLING-2788 integration tests (for example PrivilegesInfoTest) fail as the UserAdmin and GroupAdmin don't initially exist. In Jackrabbit those groups are apparently created by UserAccessControlProvider [1] - I'll ask the Oak team how to have the equivalent in Oak. As a workaround, creating those groups as follows allows a few more tests to pass - but for the final setup the groups need to be created with specific security-related parameters. curl -u admin:admin -F:name=GroupAdmin http://localhost:8080/system/userManager/group.create.html curl -u admin:admin -F:name=UserAdmin http://localhost:8080/system/userManager/group.create.html [1] http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/user/UserAccessControlProvider.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SLING-3143) CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members
[ https://issues.apache.org/jira/browse/SLING-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Sanso updated SLING-3143: - Attachment: (was: SLING-3144-patch.txt) CreateUserServlet.createUser doesn't work on Oak for UserAdmin group members Key: SLING-3143 URL: https://issues.apache.org/jira/browse/SLING-3143 Project: Sling Issue Type: Bug Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3143-forceAdminSession.patch CreateUserServlet.createUser detects if the current user is a member of the UserAdmin group (group name is configurable), and if that's the case considers the user as admin and uses its session to create a new user. This fails on Oak, our launchpad/integration-tests CreateUserTest fails. I'll attach a patch that works around the problem by forcing the use of an admin session in this case, but I'm not sure if it's the right thing to do, I'll discuss on the dev list. -- This message was sent by Atlassian JIRA (v6.1#6144)
Build failed in Jenkins: sling-trunk-1.7 #324
See https://builds.apache.org/job/sling-trunk-1.7/324/ -- [...truncated 309 lines...] Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:507) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) ... 14 more Caused by: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 33 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E204899: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: E204899: Cannot create new file '/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:748) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) ... 32 more Caused by: svn: E204899: REPORT request failed on '/repos/asf/!svn/vcc/default' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:407) ... 34 more Caused by: svn: E204899: Cannot create new file '/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126) at org.tmatesoft.svn.core.internal.wc.SVNFileUtil.createEmptyFile(SVNFileUtil.java:346) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14.createVersionedDirectory(SVNAdminArea14.java:1553) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory.doCreateVersionedDirectory(SVNAdminArea16Factory.java:30) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.createVersionedDirectory(SVNAdminAreaFactory.java:241) at org.tmatesoft.svn.core.internal.wc.SVNWCManager.ensureAdminAreaExists(SVNWCManager.java:428) at org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.addDir(SVNUpdateEditor.java:762) at org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.addDir(SVNCancellableEditor.java:84) at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVEditorHandler.startElement(DAVEditorHandler.java:326) at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.startElement(BasicDAVHandler.java:89) at
[jira] [Commented] (SLING-3028) Support for progress tracking of jobs and keeping jobs
[ https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790327#comment-13790327 ] Victor Saar commented on SLING-3028: I have no deep knowledge of the job processing bundle, but the changes generally look good to me. If the progress tracking API is missing anything will become apparent when people start using it. Support for progress tracking of jobs and keeping jobs -- Key: SLING-3028 URL: https://issues.apache.org/jira/browse/SLING-3028 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Victor Saar Assignee: Carsten Ziegeler Labels: jobs Fix For: Extensions Event 3.3.0 Attachments: SLING-3028.patch For long-running jobs, it would be useful to have some means to track progress, which can be shown in a console for the user. This should include the following: * ETA * Completeness value computed from (optional, defaults to 1.0) max and current value (e.g. 42% or 23/100) * Log output stream for detailed progress information * Failure reason in case job failed AFAICS this requires a few changes to the existing implementation: * Jobs need additional support for setting properties, e.g. max and current progress value * Jobs need to be kept at least for a while after they completed/failed to give access to failure information/log stream -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SLING-1605) Update documentation
[ https://issues.apache.org/jira/browse/SLING-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-1605: Fix Version/s: (was: Launchpad Base 2.5.2) Launchpad Base 2.5.4 Update documentation Key: SLING-1605 URL: https://issues.apache.org/jira/browse/SLING-1605 Project: Sling Issue Type: Task Components: Launchpad Reporter: Carsten Ziegeler Fix For: Launchpad Base 2.5.4 When releasing version 2.1.0 and 2.2.0 we left some tasks open to be documented: SLING-1157 SLING-922 SLING-1200 SLING-1189 SLING-1443 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (SLING-2757) Support Java 8 as a platform
[ https://issues.apache.org/jira/browse/SLING-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-2757: Fix Version/s: (was: Launchpad Base 2.5.2) Launchpad Base 2.5.4 Support Java 8 as a platform Key: SLING-2757 URL: https://issues.apache.org/jira/browse/SLING-2757 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Base 2.4.0 Reporter: Felix Meschberger Fix For: Launchpad Base 2.5.4 The Sling launchpad currently has Java platform definitions for Java 5, 6, and 7 but is lacking them for Java 8. As a consequence the framework fails to start on Java 8 platforms with exceptions such as: 26.11.2012 18:13:10.171 *ERROR* [main] ERROR: Error parsing system bundle export statement: org.osgi.framework; version=1.6, org.osgi.framework.hooks.bundle; version=1.0, org.osgi.framework.hooks.resolver; version=1.0, org.osgi.framework.hooks.service; version=1.1, org.osgi.framework.hooks.weaving; version=1.0, org.osgi.framework.launch; version=1.0, org.osgi.framework.startlevel; version=1.0, org.osgi.framework.wiring; version=1.0, org.osgi.service.packageadmin; version=1.2, org.osgi.service.startlevel; version=1.1, org.osgi.service.url; version=1.0, org.osgi.util.tracker;version=1.5, org.apache.sling.launchpad.api;version=1.1.0, (org.osgi.framework.BundleException: Exported package names cannot be zero length.) org.osgi.framework.BundleException: Exported package names cannot be zero length. at org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeExportClauses(ManifestParser.java:729) at org.apache.felix.framework.util.manifestparser.ManifestParser.init(ManifestParser.java:191) at org.apache.felix.framework.ExtensionManager.init(ExtensionManager.java:221) at org.apache.felix.framework.Felix.init(Felix.java:374) at org.apache.sling.launchpad.base.impl.SlingFelix.init(SlingFelix.java:45) at org.apache.sling.launchpad.base.impl.Sling.createFramework(Sling.java:343) at org.apache.sling.launchpad.base.impl.Sling.init(Sling.java:212) at org.apache.sling.launchpad.base.app.MainDelegate$1.init(MainDelegate.java:183) at org.apache.sling.launchpad.base.app.MainDelegate.start(MainDelegate.java:183) at org.apache.sling.launchpad.app.Main.doStart(Main.java:386) at org.apache.sling.launchpad.app.Main.doStart(Main.java:322) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3144) UserAdmin and GroupAdmin groups are missing on our Oak setup
[ https://issues.apache.org/jira/browse/SLING-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790330#comment-13790330 ] Bertrand Delacretaz commented on SLING-3144: I haven't tested your patch but creating the UserAdmin and GroupAdmin groups just for the tests looks good to me. In addition, I would suggest having a look at the CreateUserServlet and CreateGroupServlet, and make sure they return a 403 forbidden HTTP status and log a descriptive message if these groups are missing. That can happen in distinct issues of course. UserAdmin and GroupAdmin groups are missing on our Oak setup Key: SLING-3144 URL: https://issues.apache.org/jira/browse/SLING-3144 Project: Sling Issue Type: Bug Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3144-patch.txt Some of my SLING-2788 integration tests (for example PrivilegesInfoTest) fail as the UserAdmin and GroupAdmin don't initially exist. In Jackrabbit those groups are apparently created by UserAccessControlProvider [1] - I'll ask the Oak team how to have the equivalent in Oak. As a workaround, creating those groups as follows allows a few more tests to pass - but for the final setup the groups need to be created with specific security-related parameters. curl -u admin:admin -F:name=GroupAdmin http://localhost:8080/system/userManager/group.create.html curl -u admin:admin -F:name=UserAdmin http://localhost:8080/system/userManager/group.create.html [1] http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/user/UserAccessControlProvider.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3144) UserAdmin and GroupAdmin groups are missing on our Oak setup
[ https://issues.apache.org/jira/browse/SLING-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790352#comment-13790352 ] Antonio Sanso commented on SLING-3144: -- thanks [~bdelacretaz] bq. In addition, I would suggest having a look at the CreateUserServlet and CreateGroupServlet, and make sure they return a 403 forbidden HTTP status and log a descriptive message if these groups are missing. another option is to change the default of the properties that expect those groups to empty. IMHO is wrong to count on the presence of them. WDYT? UserAdmin and GroupAdmin groups are missing on our Oak setup Key: SLING-3144 URL: https://issues.apache.org/jira/browse/SLING-3144 Project: Sling Issue Type: Bug Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Attachments: SLING-3144-patch.txt Some of my SLING-2788 integration tests (for example PrivilegesInfoTest) fail as the UserAdmin and GroupAdmin don't initially exist. In Jackrabbit those groups are apparently created by UserAccessControlProvider [1] - I'll ask the Oak team how to have the equivalent in Oak. As a workaround, creating those groups as follows allows a few more tests to pass - but for the final setup the groups need to be created with specific security-related parameters. curl -u admin:admin -F:name=GroupAdmin http://localhost:8080/system/userManager/group.create.html curl -u admin:admin -F:name=UserAdmin http://localhost:8080/system/userManager/group.create.html [1] http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/user/UserAccessControlProvider.html -- This message was sent by Atlassian JIRA (v6.1#6144)
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #1956
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/1956/
Jenkins build became unstable: sling-trunk-1.6 #1956
See https://builds.apache.org/job/sling-trunk-1.6/1956/changes
Build failed in Jenkins: sling-trunk-1.7 #325
See https://builds.apache.org/job/sling-trunk-1.7/325/ -- [...truncated 298 lines...] Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:507) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) ... 14 more Caused by: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 33 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E204899: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: E204899: Cannot create new file '/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:748) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) ... 32 more Caused by: svn: E204899: REPORT request failed on '/repos/asf/!svn/vcc/default' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:407) ... 34 more Caused by: svn: E204899: Cannot create new file '/home/hudson/jenkins-slave/workspace/sling-trunk-1.7/trunk/samples/espblog/src/main/java/org/apache/sling/samples/espblog/.svn/lock' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:171) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:126) at org.tmatesoft.svn.core.internal.wc.SVNFileUtil.createEmptyFile(SVNFileUtil.java:346) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14.createVersionedDirectory(SVNAdminArea14.java:1553) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea16Factory.doCreateVersionedDirectory(SVNAdminArea16Factory.java:30) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.createVersionedDirectory(SVNAdminAreaFactory.java:241) at org.tmatesoft.svn.core.internal.wc.SVNWCManager.ensureAdminAreaExists(SVNWCManager.java:428) at org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.addDir(SVNUpdateEditor.java:762) at org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.addDir(SVNCancellableEditor.java:84) at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVEditorHandler.startElement(DAVEditorHandler.java:326) at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.startElement(BasicDAVHandler.java:89) at
JIRA access
Hello everyone, I was hoping to cut my teeth contributing to Sling by looking into integration tests for SLING-999https://issues.apache.org/jira/browse/SLING-999. (If it's still a relevant issue? If not, I'd be happy to take a steer on something else). I was just wondering the process — I've basic JIRA access, but can't assign the issue to myself. Thought possibly I should request contributor access here, or should I create a patch first attach? Best Dave Confidentiality notice This communication is from LBi Ltd, a private limited company registered in Scotland with registered number SC177425 having its registered office at 51 Timberbush, Edinburgh, EH6 6QH. DigitasLBi is a trading name of LBi Limited. This electronic message contains information which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail as above immediately.
Re: JIRA access
Hi, On Wed, Oct 9, 2013 at 4:04 PM, David Moloney david.molo...@lbi.com wrote: ...I was hoping to cut my teeth contributing to Sling by looking into integration tests for SLING-999... Cool! AFAIK that's still relevant. Thought possibly I should request contributor access here, or should I create a patch first attach?... You can create and attach a patch, and we can then grant you contributor status as needed. Have fun! -Bertrand
[jira] [Updated] (SLING-3155) Switch launchpad between Jackrabbit and Oak based on run modes
[ https://issues.apache.org/jira/browse/SLING-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-3155: --- Attachment: SLING-3155.patch Here's a first shot at a patch that installs only a minimal set of bundles via the bootstrap mechanism, and lets the OSGi installer install most bundles. The OSGi installer can then take run modes into account, which the bootstrap installer doesn't do. This is not finished, see tODOs in the patch, but I won't be working on this in the next few days and I know [~asanso] is looking at the Oak stuff, so this patch might help if you want to finish this before I get back to it. Also, with this patch the org.apache.sling.commons.log doesn't start, but starting it manually from the webconsole works. Switch launchpad between Jackrabbit and Oak based on run modes -- Key: SLING-3155 URL: https://issues.apache.org/jira/browse/SLING-3155 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Attachments: SLING-3155.patch We need this to run our integration tests on both Jackrabbit and Oak. Using -Dsling.run.modes=jackrabbit (or oak) on the first startup of the launchpad runnable jar will switch. These run modes need to be set to be mutually exclusive and considered only on the first startup, we don't support switching later. We'll need to support upgrading a Jackrabbit repository to Oak but that's a different issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SLING-3156) Add bundles support to Launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-3156. Resolution: Won't Fix Not needed indeed, I have attached a patch to SLING-3155 that will enable run mode-based bundle selection. Add bundles support to Launchpad installer -- Key: SLING-3156 URL: https://issues.apache.org/jira/browse/SLING-3156 Project: Sling Issue Type: Improvement Components: Launchpad Affects Versions: Launchpad Installer 1.2.0 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz The launchpad installer currently supports only configurations, but for SLING-3155 we need to provide runmode-dependent bundles to the OSGi installer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (SLING-3157) Launchpad bootstrap: prepare bundles for launchpad installer
[ https://issues.apache.org/jira/browse/SLING-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-3157. Resolution: Won't Fix Not needed indeed, I have attached a patch to SLING-3155 that will enable run mode-based bundle selection. Launchpad bootstrap: prepare bundles for launchpad installer Key: SLING-3157 URL: https://issues.apache.org/jira/browse/SLING-3157 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Once SLING-3156 is implemented we'll need to modify the launchpad bootstrap code to copy the runmode-dependent bundles to where the launchpad installer expects to find them. Currently, bundles found in the launchpad jar under paths like resources/bundles.foo/5 (for runmode foo and run level 5) are ignored by the bootstrap installer, we might just need to copy those to the right filesystem folder. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.
[ https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790445#comment-13790445 ] Ian Boston commented on SLING-3154: --- I am thinking of a different approach. Embed everything inside the discovery implementation (it is an implementation after all) and support whitelist or signing with optional encryption of the payload. This should make it much simpler for anyone to configure. Adding a SPI only becomes relevant if the internal impl doesn't cover whats needed, and if there is an SPI, then the impl becomes more complex. Add Topology Message Verification to the Discovery service. --- Key: SLING-3154 URL: https://issues.apache.org/jira/browse/SLING-3154 Project: Sling Issue Type: Improvement Components: General Affects Versions: Discovery Impl 1.0.0 Reporter: Ian Boston Assignee: Ian Boston Fix For: Discovery Impl 1.0.2 The discovery service provides support for whitelisting sources of topology information, but in a cluster where the topology this creates a re-configuration load of order M*(n*(n-1)) where n is the number of nodes in the topology and M is the number of changes. That load rises rapidly as the number of changes and/or nodes increases. To address this there are 2 proposals. 1. To provide an SPI exported from the Discovery Impl bundle that allows implementors to implement whitelisting based on the request. This will need to support creating the request and validating the request. 2. Embed functionality within the Discovery Impl bundle that supports validation and encryption of topology requests. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.
[ https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790458#comment-13790458 ] Stefan Egli commented on SLING-3154: Hi [~ianeboston], not quite sure I follow you here. Whitelisting is already supported but if I understand the reason for this ticket correctly, then it was the limited nature of the current whitelisting feature which is not 'enough' - hence, an API (or SPI..) for doing custom whitelisting - as you suggested on the list - to me does make a lot of sense. Or asked differently: how would the whitelisting feature you require for your use case look like (that would be generalizable enough to be put in the discovery.impl)? Regarding encrypting/decrypting: do we have all the APIs on the Sling level for this? Cheers, Stefan Add Topology Message Verification to the Discovery service. --- Key: SLING-3154 URL: https://issues.apache.org/jira/browse/SLING-3154 Project: Sling Issue Type: Improvement Components: General Affects Versions: Discovery Impl 1.0.0 Reporter: Ian Boston Assignee: Ian Boston Fix For: Discovery Impl 1.0.2 The discovery service provides support for whitelisting sources of topology information, but in a cluster where the topology this creates a re-configuration load of order M*(n*(n-1)) where n is the number of nodes in the topology and M is the number of changes. That load rises rapidly as the number of changes and/or nodes increases. To address this there are 2 proposals. 1. To provide an SPI exported from the Discovery Impl bundle that allows implementors to implement whitelisting based on the request. This will need to support creating the request and validating the request. 2. Embed functionality within the Discovery Impl bundle that supports validation and encryption of topology requests. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: TopologyConnectorServlet
Hi
Am 08.10.2013 um 10:40 schrieb Ian Boston:
Hi,
The whitelist configuration in this servlet is causing some problems
where the contents of the whitelist is potentially large and changing,
since it requires constant re-configuration.
What is the problem with that ?
And why would a service API help mitigate that issue ? Considering that service
would have to be reconfigured, too, and your code sample belows uses a static
reference ?
Also, noted in another thread, this would require export of the API from the
impl bundle, which I am not very happy with...
Finally -- and this is purely subjective -- I am not very happy with the name
WhiteListProvider and then WhiteListProvider.isWhiteListed... Also would there
be other needs for hooking into this servlet ?
Regards
Felix
Would it be possible to have a API service that is consulted if
present to check if the request is allowed. For those that want to use
the service they would configure the whitelist to reject everything
while the service was not present so avoid startup issues.
eg
+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
+ private WhiteListProvider whiteListProvider;
/** Checks if the provided request's remote server is whitelisted **/
private boolean isWhitelisted(final SlingHttpServletRequest request) {
+ if (whiteListProvider != null) {
+ whiteListProvider.isWhitelisted(request);
+}
if (whitelist.contains(request.getRemoteAddr())) {
return true;
} else if (whitelist.contains(request.getRemoteHost())) {
return true;
}
logger.info(isWhitelisted: rejecting + request.getRemoteAddr()
+ , + request.getRemoteHost());
return false;
}
and in the API, presumably discovery api.
public interface WhiteListProvider {
private boolean isWhitelisted(HttpServletRequest request);
}
Best Regards
Ian
smime.p7s
Description: S/MIME cryptographic signature
Re: TopologyConnectorServlet
Hi,
On 9 October 2013 16:21, Felix Meschberger fmesc...@adobe.com wrote:
Hi
Am 08.10.2013 um 10:40 schrieb Ian Boston:
Hi,
The whitelist configuration in this servlet is causing some problems
where the contents of the whitelist is potentially large and changing,
since it requires constant re-configuration.
What is the problem with that ?
When the whitelist in the central discovery endpoint depends on the
topology itself, it causes production deployment problems, especially
when the configuration of the end point and the management of the
topology of the production deployment are managed by different roles
within the organisation. This is typical of many organisations.
Engineers don't manage operations and TechOps don't manage
engineering. Normally configuration would be managed by TechOps but
with Sling that doesn't appear to be the case. Consequently the 2 get
out of sync, and if you are using Sling Discovery to transport
metadata about your topology, lots of things start to break when nodes
are not in the whitelist.
In our special case we have 1 central discovery end point, if we had
n, the problem would multiply by n.
And why would a service API help mitigate that issue ?
It would give those that are able to see the deployment infrastructure
that they are dealing with, the opportunity to address this issue.
Considering that service would have to be reconfigured, too, and your code
sample belows uses a static reference ?
AFAIK it uses an optional reference, satisfied by a implementation
outside Sling. The snippet was written from memory directly into the
email to communicate what I was trying to discuss. Its is not real
code.
Also, noted in another thread, this would require export of the API from the
impl bundle, which I am not very happy with...
Finally -- and this is purely subjective -- I am not very happy with the name
WhiteListProvider and then WhiteListProvider.isWhiteListed... Also would
there be other needs for hooking into this servlet ?
I have been working on an implementation most of the day that is
nothing like what was first discussed, I will commit in a moment. Much
better to share real code with unit test coverage.
Best Regards
Ian
Regards
Felix
Would it be possible to have a API service that is consulted if
present to check if the request is allowed. For those that want to use
the service they would configure the whitelist to reject everything
while the service was not present so avoid startup issues.
eg
+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
+ private WhiteListProvider whiteListProvider;
/** Checks if the provided request's remote server is whitelisted **/
private boolean isWhitelisted(final SlingHttpServletRequest request) {
+ if (whiteListProvider != null) {
+ whiteListProvider.isWhitelisted(request);
+}
if (whitelist.contains(request.getRemoteAddr())) {
return true;
} else if (whitelist.contains(request.getRemoteHost())) {
return true;
}
logger.info(isWhitelisted: rejecting + request.getRemoteAddr()
+ , + request.getRemoteHost());
return false;
}
and in the API, presumably discovery api.
public interface WhiteListProvider {
private boolean isWhitelisted(HttpServletRequest request);
}
Best Regards
Ian
[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.
[ https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790563#comment-13790563 ] Ian Boston commented on SLING-3154: --- Hi [~egli] I need the ability to have a single shared configuration for an entire topology that allows automated and secure discovery of all active members of that topology without any whitelisting. That configuration should be static and not dependent on the topology itself or reference anything in the physical topology. Regarding encrypting/decrypting: do we have all the APIs on the Sling level for this? I might be missing something but last time I looked the JDK supported encrypting/decrypting. It may not have a huge range of algorithms, but HmacSHA256 and AES/CBC/PKCS5Padding is probably good enough for this. I have working code that doesn't do anything to the existing IP whitelisting unless configured to be active. Best Regards Ian Add Topology Message Verification to the Discovery service. --- Key: SLING-3154 URL: https://issues.apache.org/jira/browse/SLING-3154 Project: Sling Issue Type: Improvement Components: General Affects Versions: Discovery Impl 1.0.0 Reporter: Ian Boston Assignee: Ian Boston Fix For: Discovery Impl 1.0.2 The discovery service provides support for whitelisting sources of topology information, but in a cluster where the topology this creates a re-configuration load of order M*(n*(n-1)) where n is the number of nodes in the topology and M is the number of changes. That load rises rapidly as the number of changes and/or nodes increases. To address this there are 2 proposals. 1. To provide an SPI exported from the Discovery Impl bundle that allows implementors to implement whitelisting based on the request. This will need to support creating the request and validating the request. 2. Embed functionality within the Discovery Impl bundle that supports validation and encryption of topology requests. -- This message was sent by Atlassian JIRA (v6.1#6144)
Build failed in Jenkins: sling-trunk-1.6 #1957
See https://builds.apache.org/job/sling-trunk-1.6/1957/changes Changes: [cziegeler] SLING-3139 : Provide a way to schedule jobs -- [...truncated 14595 lines...] 09.10.2013 14:15:50.098 *INFO* [main] org.apache.sling.event Service [org.apache.sling.event.impl.jobs.deprecated.JobStatusProviderImpl,95] ServiceEvent REGISTERED 09.10.2013 14:15:55.107 *WARN* [Apche Sling JCR Resource Event Queue Processor for path '/'] org.apache.felix.eventadmin EventAdmin: Blacklisting ServiceReference [[org.apache.sling.event.jobs.JobManager, org.osgi.service.event.EventHandler, org.apache.sling.discovery.TopologyEventListener, java.lang.Runnable] | Bundle(org.apache.sling.event [66])] due to timeout! Build timed out (after 150 minutes). Marking the build as failed. Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Reactor Summary: Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling JAR Resource Bundle .. SUCCESS [18.559s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling (Parent) . SUCCESS [5.311s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Sling Adapter Annotations . SUCCESS [5.892s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling Maven Plugin to create Jackrabbit OCM descriptors SUCCESS [4.932s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling Maven Plugin for Compiling JSP Sources into Bundles SUCCESS [5.577s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling Maven Plugin for Supporting Bundle Development SUCCESS [4.261s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling Launchpad Maven Plugin ... SUCCESS [19.476s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Sling Launchpad Standalone Archetype .. SUCCESS [4.601s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Sling Launchpad Webapp Archetype .. SUCCESS [3.246s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Sling Initial Content Archetype ... SUCCESS [3.020s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Sling Servlet Archetype ... SUCCESS [10.588s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Sling Bundle Archetype SUCCESS [2.731s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Sling JCRInstall Bundle Archetype . SUCCESS [7.749s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Sling Taglib Archetype SUCCESS [3.102s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling API .. SUCCESS [9.748s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling Service User Mapper .. SUCCESS [5.600s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling Resource Resolver SUCCESS [7.586s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling System Bundle Extension: Java Transaction API SUCCESS [2.981s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling System Bundle Extension: XML APIs SUCCESS [3.342s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling System Bundle Extension: Activation API SUCCESS [2.833s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling System Bundle Extension: WS APIs . SUCCESS [2.987s] Oct 9, 2013 4:32:41 PM org.apache.maven.cli.event.ExecutionEventLogger logReactorSummary INFO: Apache Sling Dynamic Class Loader Support . SUCCESS [10.541s] Oct 9, 2013 4:32:41 PM
[jira] [Commented] (SLING-3154) Add Topology Message Verification to the Discovery service.
[ https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790633#comment-13790633 ] Ian Boston commented on SLING-3154: --- Changes committed with code coverage for the new code for the passing use cases. Verified no impact on current implementation, as none of the existing tests were touched. All discovery bundles build and pass tests. Will need to deploy so some live instances and configure to validate in the wild. This is a brief description Uses HmacSHA256 with a derived key that lasts 4h for signatures. Uses AES/CBC/PKCS5Padding with a 128 bit key and random 9 byte salt for encryption if enabled. Configuration is via the Config Component. To enable white listing is turned off, a shared key is set and optionally, encryption and the signature key lifetime is set. Signature is performed by performing a HMAC on a SHA of the body, url and direction message (request or response). The SHA is put in X-SlingTopologyHash header, the HMAC is put in X-SlingTopologyTrust header. Verifying the message can be trusted rebuilds checks that the HMAC of the SHA is the same as in the request. No reference is made to the body of the request. When extracting the body of the request or response the SHA is rebuilt and checked against the body of the message (encrypted if the body was encrypted) Encryption takes the String body, and encrypts into a json object with a single key payload containing a JSONArray made up of the base64 encoded 10 byte salt, the Cipher initialisation vector as base64 encoded bytes, and the encrypted data. Decryption uses the salt to generate the key and initialisation vector to decrypt the data. It is possible to replay the same identical message 2x. It is not possible to replay a different message using an old hash/hmac It is not possible to replay an empty message (eg DELETE, where the body is null) on different urls. Requests and responses do not share hash/hmac pairs and both directions are secured. I will leave the issue open in case there objections to this change from the community or if testing turns up issues. Add Topology Message Verification to the Discovery service. --- Key: SLING-3154 URL: https://issues.apache.org/jira/browse/SLING-3154 Project: Sling Issue Type: Improvement Components: General Affects Versions: Discovery Impl 1.0.0 Reporter: Ian Boston Assignee: Ian Boston Fix For: Discovery Impl 1.0.2 The discovery service provides support for whitelisting sources of topology information, but in a cluster where the topology this creates a re-configuration load of order M*(n*(n-1)) where n is the number of nodes in the topology and M is the number of changes. That load rises rapidly as the number of changes and/or nodes increases. To address this there are 2 proposals. 1. To provide an SPI exported from the Discovery Impl bundle that allows implementors to implement whitelisting based on the request. This will need to support creating the request and validating the request. 2. Embed functionality within the Discovery Impl bundle that supports validation and encryption of topology requests. -- This message was sent by Atlassian JIRA (v6.1#6144)
Jenkins build is back to normal : sling-trunk-1.7 #326
See https://builds.apache.org/job/sling-trunk-1.7/326/changes
Jenkins build is back to normal : sling-trunk-1.6 #1958
See https://builds.apache.org/job/sling-trunk-1.6/1958/changes
Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Testing #1958
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/1958/
Re: TopologyConnectorServlet
Hi
Am 09.10.2013 um 09:05 schrieb Ian Boston:
Hi,
On 9 October 2013 16:21, Felix Meschberger fmesc...@adobe.com wrote:
Hi
Am 08.10.2013 um 10:40 schrieb Ian Boston:
Hi,
The whitelist configuration in this servlet is causing some problems
where the contents of the whitelist is potentially large and changing,
since it requires constant re-configuration.
What is the problem with that ?
When the whitelist in the central discovery endpoint depends on the
topology itself, it causes production deployment problems, especially
when the configuration of the end point and the management of the
topology of the production deployment are managed by different roles
within the organisation. This is typical of many organisations.
Engineers don't manage operations and TechOps don't manage
engineering. Normally configuration would be managed by TechOps but
Fully agreed ! Which is exactly the reason why conceptually we have to separate
development from deployment and which is why configuration *is* in fact a
deployment issue and not a development issue.
with Sling that doesn't appear to be the case.
How come ? That is not the intent of how Sling should be used.
Consequently the 2 get
out of sync, and if you are using Sling Discovery to transport
metadata about your topology, lots of things start to break when nodes
are not in the whitelist.
Sure, if developers want to be involved with deployment, things run havock.
In our special case we have 1 central discovery end point, if we had
n, the problem would multiply by n.
And why would a service API help mitigate that issue ?
It would give those that are able to see the deployment infrastructure
that they are dealing with, the opportunity to address this issue.
Considering that service would have to be reconfigured, too, and your code
sample belows uses a static reference ?
AFAIK it uses an optional reference, satisfied by a implementation
outside Sling. The snippet was written from memory directly into the
email to communicate what I was trying to discuss. Its is not real
code.
Also, noted in another thread, this would require export of the API from the
impl bundle, which I am not very happy with...
Finally -- and this is purely subjective -- I am not very happy with the
name WhiteListProvider and then WhiteListProvider.isWhiteListed... Also
would there be other needs for hooking into this servlet ?
I have been working on an implementation most of the day that is
nothing like what was first discussed, I will commit in a moment. Much
better to share real code with unit test coverage.
Ok.
Regards
Felix
Best Regards
Ian
Regards
Felix
Would it be possible to have a API service that is consulted if
present to check if the request is allowed. For those that want to use
the service they would configure the whitelist to reject everything
while the service was not present so avoid startup issues.
eg
+@Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY)
+ private WhiteListProvider whiteListProvider;
/** Checks if the provided request's remote server is whitelisted **/
private boolean isWhitelisted(final SlingHttpServletRequest request) {
+ if (whiteListProvider != null) {
+ whiteListProvider.isWhitelisted(request);
+}
if (whitelist.contains(request.getRemoteAddr())) {
return true;
} else if (whitelist.contains(request.getRemoteHost())) {
return true;
}
logger.info(isWhitelisted: rejecting + request.getRemoteAddr()
+ , + request.getRemoteHost());
return false;
}
and in the API, presumably discovery api.
public interface WhiteListProvider {
private boolean isWhitelisted(HttpServletRequest request);
}
Best Regards
Ian
smime.p7s
Description: S/MIME cryptographic signature
Re: JIRA access
Hi Or better yet, create new issues pertaining to concrete tests you add. BTW: Thanks a lot for taking a stab. This is very much appreciated. Regards Felix Am 09.10.2013 um 07:19 schrieb Bertrand Delacretaz: Hi, On Wed, Oct 9, 2013 at 4:04 PM, David Moloney david.molo...@lbi.com wrote: ...I was hoping to cut my teeth contributing to Sling by looking into integration tests for SLING-999... Cool! AFAIK that's still relevant. Thought possibly I should request contributor access here, or should I create a patch first attach?... You can create and attach a patch, and we can then grant you contributor status as needed. Have fun! -Bertrand smime.p7s Description: S/MIME cryptographic signature
