CLI commands removed in an Boron SR


Colin Dixon <colin@...>
 

So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.

That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.

This patch seems to be the issue:

Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?

Thanks,
--Colin


Ryan Goulding <ryandgoulding@...>
 

which is probably not in the spirit of SRs

This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.

 While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j

This isn't a feature, it is CLI.

 This patch seems to be the issue:
https://git.opendaylight.org/gerrit/#/c/51649/

Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!

Regards,

Ryan Goulding


On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.

That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.

This patch seems to be the issue:

Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?

Thanks,
--Colin


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



Colin Dixon <colin@...>
 

Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?

--Colin 

On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
which is probably not in the spirit of SRs

This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.

 While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j

This isn't a feature, it is CLI.

 This patch seems to be the issue:
https://git.opendaylight.org/gerrit/#/c/51649/

Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!

On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.

That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.

This patch seems to be the issue:

Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?

Thanks,
--Colin


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



Mohamed ElSerngawy <melserngawy@...>
 

Hi Colin,

You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.   

BR

On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?

--Colin 

On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
which is probably not in the spirit of SRs

This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.

 While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j

This isn't a feature, it is CLI.

 This patch seems to be the issue:
https://git.opendaylight.org/gerrit/#/c/51649/

Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!

On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.

That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.

This patch seems to be the issue:

Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?

Thanks,
--Colin


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev




Luis Gomez
 

hi guys, I just tested old-aaa-cert feature and couple of things:

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?


[1] NPE

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 500 Server Error</title>
</head>
<body>
<h2>HTTP ERROR 500</h2>
<p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:

<pre> Server Error</pre>
</p>
<h3>Caused by:</h3>
<pre>java.lang.NullPointerException
at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)

On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:

Hi Colin,

You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.

BR

On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?

--Colin

On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
which is probably not in the spirit of SRs

This was done for both usability and security purposes, as I explained via Skype already. The security advantages alone make it justifiable IMHO.

While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j

This isn't a feature, it is CLI.

This patch seems to be the issue:
https://git.opendaylight.org/gerrit/#/c/51649/

Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;). Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!

Regards,

Ryan Goulding

[0] https://bugs.opendaylight.org/show_bug.cgi?id=7774

On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.

That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.

This patch seems to be the issue:
https://git.opendaylight.org/gerrit/#/c/51649/

Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?

Thanks,
--Colin


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev


Jamo Luhrsen <jluhrsen@...>
 

btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html

On 04/26/2017 06:21 PM, Luis Gomez wrote:
hi guys, I just tested old-aaa-cert feature and couple of things:

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?


[1] NPE

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 500 Server Error</title>
</head>
<body>
<h2>HTTP ERROR 500</h2>
<p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:

<pre> Server Error</pre>
</p>
<h3>Caused by:</h3>
<pre>java.lang.NullPointerException
at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)





On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:

Hi Colin,

You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.

BR

On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?

--Colin

On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
which is probably not in the spirit of SRs

This was done for both usability and security purposes, as I explained via Skype already. The security advantages alone make it justifiable IMHO.

While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j

This isn't a feature, it is CLI.

This patch seems to be the issue:
https://git.opendaylight.org/gerrit/#/c/51649/

Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;). Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!

Regards,

Ryan Goulding

[0] https://bugs.opendaylight.org/show_bug.cgi?id=7774

On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.

That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.

This patch seems to be the issue:
https://git.opendaylight.org/gerrit/#/c/51649/

Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?

Thanks,
--Colin


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev
_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev


Colin Dixon <colin@...>
 

Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>


Ryan Goulding <ryandgoulding@...>
 

The stuff you are referring to works, JamO, and is completely orthogonal to the issue Luis reports.  If you paste the exact REST call I can assist.  Also, if you are curious how to use those endpoints, refer to idmtool.py, which just wraps that interface.  I just tested this morning.
 

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
I'll give it a shot and see what I get.

Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

So far we haven't demonstrated that the patch does anything negative except deprecate some unsafe commands.  Although revert may probably be easiest from your perspective, there are a lot of people who actually push their tests upstream and avoid this type of skew.  Let's not start a witch hunt quite yet;  I can pull up quite a few examples of far more risque changes in service releases ;).

Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>

_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



Mohamed ElSerngawy <melserngawy@...>
 

Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>


Ryan Goulding <ryandgoulding@...>
 

Works for me...

ryan@ubuntu:/code/aaa-nitrogen/karaf/target/assembly$ curl -u admin:admin -X POST -v http://localhost:8181/restconf/operations/aaa-cert-rpc:getODLCertificate
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8181 (#0)
* Server auth using Basic with user 'admin'
> POST /restconf/operations/aaa-cert-rpc:getODLCertificate HTTP/1.1
> Host: localhost:8181
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.47.0
> Accept: */*
< HTTP/1.1 200 OK
< Set-Cookie: JSESSIONID=1c7rj2qb91h8vpm7sba4j444r;Path=/restconf
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: rememberMe=deleteMe; Path=/restconf; Max-Age=0; Expires=Wed, 26-Apr-2017 14:06:26 GMT
< Content-Type: application/yang.operation+json
< Transfer-Encoding: chunked
* Connection #0 to host localhost left intact
{"output":{"odl-cert":"MIICKTCCAZKgAwIBAgIEcp0NTDANBgkqhkiG9w0BAQUFADBZMQwwCgYDVQQDDANPREwxDDAKBgNVBAsMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVhbDELMAkGA1UEBhMCQ0EwHhcNMTcwNDI3MTM1ODU4WhcNMTgwNDI3MTM1ODU4WjBZMQwwCgYDVQQDDANPREwxDDAKBgNVBAsMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVhbDELMAkGA1UEBhMCQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJtRMT40niJzHGUewHeTKLujY3Wfp1A/AStwLsm554m4nKcq1g8+vkcQbfMijaDZkFRrKM/x7kI9BnjCkbADHbnYE3Zgf+o52wuUEHXeS21Bq2TL0+TFlazel+xlySUH+L+PAygs1Giq1WTf7to3VSStILzmL8DbjUrcsZPt/185AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAbHA5eVO2KZQSMvFehH1/tGmqkUYzWRAq8wrOlD5zdGuqvv9YBuBL/rScytAJ9qTHvhVYcW17Ch2IHeuMoEyym6DCLSmgegPiCptdMjQ7+9FNzSFf/lIKhtDhK7Nzm0F2u44utAJ5qfj3ZUWnq5LjIWaxocfeYIi0KXKyaNZGPfE="}}



Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



Ryan Goulding <ryandgoulding@...>
 

Actually scratch that @Luis, I get the same thing with boron-sr3.  The output above is from carbon (I was confused due to the fact that the patch referenced was in carbon).  There appears to be something screwy in boron-sr3...

Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 10:07 AM, Ryan Goulding <ryandgoulding@...> wrote:
Works for me...

ryan@ubuntu:/code/aaa-nitrogen/karaf/target/assembly$ curl -u admin:admin -X POST -v http://localhost:8181/restconf/operations/aaa-cert-rpc:getODLCertificate
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8181 (#0)
* Server auth using Basic with user 'admin'
> POST /restconf/operations/aaa-cert-rpc:getODLCertificate HTTP/1.1
> Host: localhost:8181
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.47.0
> Accept: */*
< HTTP/1.1 200 OK
< Set-Cookie: JSESSIONID=1c7rj2qb91h8vpm7sba4j444r;Path=/restconf
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: rememberMe=deleteMe; Path=/restconf; Max-Age=0; Expires=Wed, 26-Apr-2017 14:06:26 GMT
< Content-Type: application/yang.operation+json
< Transfer-Encoding: chunked
* Connection #0 to host localhost left intact
{"output":{"odl-cert":"MIICKTCCAZKgAwIBAgIEcp0NTDANBgkqhkiG9w0BAQUFADBZMQwwCgYDVQQDDANPREwxDDAKBgNVBAsMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVhbDELMAkGA1UEBhMCQ0EwHhcNMTcwNDI3MTM1ODU4WhcNMTgwNDI3MTM1ODU4WjBZMQwwCgYDVQQDDANPREwxDDAKBgNVBAsMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVhbDELMAkGA1UEBhMCQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJtRMT40niJzHGUewHeTKLujY3Wfp1A/AStwLsm554m4nKcq1g8+vkcQbfMijaDZkFRrKM/x7kI9BnjCkbADHbnYE3Zgf+o52wuUEHXeS21Bq2TL0+TFlazel+xlySUH+L+PAygs1Giq1WTf7to3VSStILzmL8DbjUrcsZPt/185AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAbHA5eVO2KZQSMvFehH1/tGmqkUYzWRAq8wrOlD5zdGuqvv9YBuBL/rScytAJ9qTHvhVYcW17Ch2IHeuMoEyym6DCLSmgegPiCptdMjQ7+9FNzSFf/lIKhtDhK7Nzm0F2u44utAJ5qfj3ZUWnq5LjIWaxocfeYIi0KXKyaNZGPfE="}}



Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev




Colin Dixon <colin@...>
 

That's a link to a patch in carbon, not boron. Is that to say the functionality is broken in Boron-SR3? If so, we need to figure out if there's a work-around and if so, document it in the Boron-SR3 release notes.

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)

I _think_ those are the only CLI commands we removed. It appears as though the replacement for 1.) is just feature:install odl-aaa-cert which will create the keystores automatically now.

It's less clear what the replacement to 2.) is. It appears as though the RPCs which should replace them throw NPEs. Is the workaround until we fix that (in Boron-SR4?) to use keytool from the Linux CLI?

--Colin


On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>



Mohamed ElSerngawy <melserngawy@...>
 

Hi Luis,

I test the aa-cert RPCs with Boron and it works fine, did u change the aaa-cert-config.xml file ? I guess you may missed that. basically you need to change the <use-config> to true if you want to use keystore files and change <use-mdsal> true if you want to store  the keystores in mdsal. Then don't forget to restart karaf. check the wiki for more info


Hi Colin,

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
yes, just after installing the aaa-cert feature and changing the aaa-cert-config the keystore will be created. You can also use the java keytool commands to create the keystore instead. Moreover, If you wish to use a pre-created keystores signed by CA just copy those files to  directory configuration/ssl/ and change the aaa-cert-config.xml <use-config> to true  odl will use those files

2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)
use the RPCs to do this.

BR

On Thu, Apr 27, 2017 at 11:46 AM, Colin Dixon <colin@...> wrote:
That's a link to a patch in carbon, not boron. Is that to say the functionality is broken in Boron-SR3? If so, we need to figure out if there's a work-around and if so, document it in the Boron-SR3 release notes.

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)

I _think_ those are the only CLI commands we removed. It appears as though the replacement for 1.) is just feature:install odl-aaa-cert which will create the keystores automatically now.

It's less clear what the replacement to 2.) is. It appears as though the RPCs which should replace them throw NPEs. Is the workaround until we fix that (in Boron-SR4?) to use keytool from the Linux CLI?

--Colin


On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>




Ryan Goulding <ryandgoulding@...>
 

I admittedly missed this configuration as well!


On Apr 27, 2017, at 12:37 PM, Mohamed ElSerngawy <melserngawy@...> wrote:

Hi Luis,

I test the aa-cert RPCs with Boron and it works fine, did u change the aaa-cert-config.xml file ? I guess you may missed that. basically you need to change the <use-config> to true if you want to use keystore files and change <use-mdsal> true if you want to store  the keystores in mdsal. Then don't forget to restart karaf. check the wiki for more info


Hi Colin,

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
yes, just after installing the aaa-cert feature and changing the aaa-cert-config the keystore will be created. You can also use the java keytool commands to create the keystore instead. Moreover, If you wish to use a pre-created keystores signed by CA just copy those files to  directory configuration/ssl/ and change the aaa-cert-config.xml <use-config> to true  odl will use those files

2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)
use the RPCs to do this.

BR

On Thu, Apr 27, 2017 at 11:46 AM, Colin Dixon <colin@...> wrote:
That's a link to a patch in carbon, not boron. Is that to say the functionality is broken in Boron-SR3? If so, we need to figure out if there's a work-around and if so, document it in the Boron-SR3 release notes.

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)

I _think_ those are the only CLI commands we removed. It appears as though the replacement for 1.) is just feature:install odl-aaa-cert which will create the keystores automatically now.

It's less clear what the replacement to 2.) is. It appears as though the RPCs which should replace them throw NPEs. Is the workaround until we fix that (in Boron-SR4?) to use keytool from the Linux CLI?

--Colin


On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>



_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev


Luis Gomez
 

Thanks Mohamed, it works in Boron with your suggestion.

So what happens is that in Boron both <use-config> and <use-mdsal> are set to false by default and as a minimum you need to set the first to true for the feature to work. In Carbon both are set to true by default so the feature works out-of-the-box.

BR/Luis


On Apr 27, 2017, at 9:37 AM, Mohamed ElSerngawy <melserngawy@...> wrote:

Hi Luis,

I test the aa-cert RPCs with Boron and it works fine, did u change the aaa-cert-config.xml file ? I guess you may missed that. basically you need to change the <use-config> to true if you want to use keystore files and change <use-mdsal> true if you want to store  the keystores in mdsal. Then don't forget to restart karaf. check the wiki for more info


Hi Colin,

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
yes, just after installing the aaa-cert feature and changing the aaa-cert-config the keystore will be created. You can also use the java keytool commands to create the keystore instead. Moreover, If you wish to use a pre-created keystores signed by CA just copy those files to  directory configuration/ssl/ and change the aaa-cert-config.xml <use-config> to true  odl will use those files

2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)
use the RPCs to do this.

BR

On Thu, Apr 27, 2017 at 11:46 AM, Colin Dixon <colin@...> wrote:
That's a link to a patch in carbon, not boron. Is that to say the functionality is broken in Boron-SR3? If so, we need to figure out if there's a work-around and if so, document it in the Boron-SR3 release notes.

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)

I _think_ those are the only CLI commands we removed. It appears as though the replacement for 1.) is just feature:install odl-aaa-cert which will create the keystores automatically now.

It's less clear what the replacement to 2.) is. It appears as though the RPCs which should replace them throw NPEs. Is the workaround until we fix that (in Boron-SR4?) to use keytool from the Linux CLI?

--Colin


On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>





Ryan Goulding <ryandgoulding@...>
 

Confirmed here as well:

ryan@ubuntu:~/Desktop/distribution-karaf-0.5.3-Boron-SR3$ curl -u admin:admin -X POST -v http://localhost:8181/restconf/operations/aaa-cert-rpc:getODLCertificate
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8181 (#0)
* Server auth using Basic with user 'admin'
> POST /restconf/operations/aaa-cert-rpc:getODLCertificate HTTP/1.1
> Host: localhost:8181
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.47.0
> Accept: */*
< HTTP/1.1 200 OK
< Set-Cookie: JSESSIONID=c68vb1yxkgge1de3149bg89f4;Path=/restconf
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: rememberMe=deleteMe; Path=/restconf; Max-Age=0; Expires=Wed, 26-Apr-2017 17:05:02 GMT
< Content-Type: application/yang.operation+json
< Transfer-Encoding: chunked
< Server: Jetty(8.1.19.v20160209)
* Connection #0 to host localhost left intact
{"output":{"odl-cert":"MIICKjCCAZOgAwIBAgIFAMJ8aK8wDQYJKoZIhvcNAQEFBQAwWTEMMAoGA1UEAwwDT0RMMQwwCgYDVQQLDANEZXYxGDAWBgNVBAoMD0xpbnV4Rm91bmRhdGlvbjEUMBIGA1UEBwwLUUMgTW9udHJlYWwxCzAJBgNVBAYTAkNBMB4XDTE3MDQyNzE3MDQ1NFoXDTE4MDQyNzE3MDQ1NFowWTEMMAoGA1UEAwwDT0RMMQwwCgYDVQQLDANEZXYxGDAWBgNVBAoMD0xpbnV4Rm91bmRhdGlvbjEUMBIGA1UEBwwLUUMgTW9udHJlYWwxCzAJBgNVBAYTAkNBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCc0BBRpaAESyUD9PRTbpS3Qx39EIt3SvZKNqw9RnUes3h7AVaBIImbjpAkCVRYrM+e5f9l2kKraTbbSf2XBvS8GeyvGpTBONAgr/R1F6i1F10Pyw3kmUKjQu7/9kMa9M/9fnNREOvIO4hOwbUvLNeU9cjNOkpXsZRC/JDVZ9RpiQIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAEOBewJgTHHdUMAG7H1yauAPKW1adKtgh1+hdasQVFz0QdzoraY8JHpffJguTB4cX0zaAen4rF5bbrY9I4KNGajrUND8WsjZ8BSOeGyX0i600ZCZxztYT2ETDKZPoWoKwONaJbdqbAuvD8RdPIW5kddZi2tOhNIsLh74NaQGMShj"}}ryan@ubuntu:~/Desktop/distribution-karaf-0.5.3-Boron-SR3$ 

Are we good with this?  I.e., can you use RPC(s) instead of CLI commands?  Trying to be helpful here :).

Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 1:01 PM, Luis Gomez <ecelgp@...> wrote:
Thanks Mohamed, it works in Boron with your suggestion.

So what happens is that in Boron both <use-config> and <use-mdsal> are set to false by default and as a minimum you need to set the first to true for the feature to work. In Carbon both are set to true by default so the feature works out-of-the-box.

BR/Luis


On Apr 27, 2017, at 9:37 AM, Mohamed ElSerngawy <melserngawy@...> wrote:

Hi Luis,

I test the aa-cert RPCs with Boron and it works fine, did u change the aaa-cert-config.xml file ? I guess you may missed that. basically you need to change the <use-config> to true if you want to use keystore files and change <use-mdsal> true if you want to store  the keystores in mdsal. Then don't forget to restart karaf. check the wiki for more info


Hi Colin,

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
yes, just after installing the aaa-cert feature and changing the aaa-cert-config the keystore will be created. You can also use the java keytool commands to create the keystore instead. Moreover, If you wish to use a pre-created keystores signed by CA just copy those files to  directory configuration/ssl/ and change the aaa-cert-config.xml <use-config> to true  odl will use those files

2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)
use the RPCs to do this.

BR

On Thu, Apr 27, 2017 at 11:46 AM, Colin Dixon <colin@...> wrote:
That's a link to a patch in carbon, not boron. Is that to say the functionality is broken in Boron-SR3? If so, we need to figure out if there's a work-around and if so, document it in the Boron-SR3 release notes.

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)

I _think_ those are the only CLI commands we removed. It appears as though the replacement for 1.) is just feature:install odl-aaa-cert which will create the keystores automatically now.

It's less clear what the replacement to 2.) is. It appears as though the RPCs which should replace them throw NPEs. Is the workaround until we fix that (in Boron-SR4?) to use keytool from the Linux CLI?

--Colin


On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>





_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



Colin Dixon <colin@...>
 

We're testing things internally to make sure this all works the way we think it does. My guess is that this will get us over the hump, but either Luis or I will follow up if not.

Thanks,
--Colin


On Thu, Apr 27, 2017 at 1:06 PM, Ryan Goulding <ryandgoulding@...> wrote:
Confirmed here as well:

ryan@ubuntu:~/Desktop/distribution-karaf-0.5.3-Boron-SR3$ curl -u admin:admin -X POST -v http://localhost:8181/restconf/operations/aaa-cert-rpc:getODLCertificate
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8181 (#0)
* Server auth using Basic with user 'admin'
> POST /restconf/operations/aaa-cert-rpc:getODLCertificate HTTP/1.1
> Host: localhost:8181
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.47.0
> Accept: */*
< HTTP/1.1 200 OK
< Set-Cookie: JSESSIONID=c68vb1yxkgge1de3149bg89f4;Path=/restconf
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: rememberMe=deleteMe; Path=/restconf; Max-Age=0; Expires=Wed, 26-Apr-2017 17:05:02 GMT
< Content-Type: application/yang.operation+json
< Transfer-Encoding: chunked
< Server: Jetty(8.1.19.v20160209)
* Connection #0 to host localhost left intact
{"output":{"odl-cert":"MIICKjCCAZOgAwIBAgIFAMJ8aK8wDQYJKoZIhvcNAQEFBQAwWTEMMAoGA1UEAwwDT0RMMQwwCgYDVQQLDANEZXYxGDAWBgNVBAoMD0xpbnV4Rm91bmRhdGlvbjEUMBIGA1UEBwwLUUMgTW9udHJlYWwxCzAJBgNVBAYTAkNBMB4XDTE3MDQyNzE3MDQ1NFoXDTE4MDQyNzE3MDQ1NFowWTEMMAoGA1UEAwwDT0RMMQwwCgYDVQQLDANEZXYxGDAWBgNVBAoMD0xpbnV4Rm91bmRhdGlvbjEUMBIGA1UEBwwLUUMgTW9udHJlYWwxCzAJBgNVBAYTAkNBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCc0BBRpaAESyUD9PRTbpS3Qx39EIt3SvZKNqw9RnUes3h7AVaBIImbjpAkCVRYrM+e5f9l2kKraTbbSf2XBvS8GeyvGpTBONAgr/R1F6i1F10Pyw3kmUKjQu7/9kMa9M/9fnNREOvIO4hOwbUvLNeU9cjNOkpXsZRC/JDVZ9RpiQIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAEOBewJgTHHdUMAG7H1yauAPKW1adKtgh1+hdasQVFz0QdzoraY8JHpffJguTB4cX0zaAen4rF5bbrY9I4KNGajrUND8WsjZ8BSOeGyX0i600ZCZxztYT2ETDKZPoWoKwONaJbdqbAuvD8RdPIW5kddZi2tOhNIsLh74NaQGMShj"}}ryan@ubuntu:~/Desktop/distribution-karaf-0.5.3-Boron-SR3$ 

Are we good with this?  I.e., can you use RPC(s) instead of CLI commands?  Trying to be helpful here :).

Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 1:01 PM, Luis Gomez <ecelgp@...> wrote:
Thanks Mohamed, it works in Boron with your suggestion.

So what happens is that in Boron both <use-config> and <use-mdsal> are set to false by default and as a minimum you need to set the first to true for the feature to work. In Carbon both are set to true by default so the feature works out-of-the-box.

BR/Luis


On Apr 27, 2017, at 9:37 AM, Mohamed ElSerngawy <melserngawy@...> wrote:

Hi Luis,

I test the aa-cert RPCs with Boron and it works fine, did u change the aaa-cert-config.xml file ? I guess you may missed that. basically you need to change the <use-config> to true if you want to use keystore files and change <use-mdsal> true if you want to store  the keystores in mdsal. Then don't forget to restart karaf. check the wiki for more info


Hi Colin,

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
yes, just after installing the aaa-cert feature and changing the aaa-cert-config the keystore will be created. You can also use the java keytool commands to create the keystore instead. Moreover, If you wish to use a pre-created keystores signed by CA just copy those files to  directory configuration/ssl/ and change the aaa-cert-config.xml <use-config> to true  odl will use those files

2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)
use the RPCs to do this.

BR

On Thu, Apr 27, 2017 at 11:46 AM, Colin Dixon <colin@...> wrote:
That's a link to a patch in carbon, not boron. Is that to say the functionality is broken in Boron-SR3? If so, we need to figure out if there's a work-around and if so, document it in the Boron-SR3 release notes.

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)

I _think_ those are the only CLI commands we removed. It appears as though the replacement for 1.) is just feature:install odl-aaa-cert which will create the keystores automatically now.

It's less clear what the replacement to 2.) is. It appears as though the RPCs which should replace them throw NPEs. Is the workaround until we fix that (in Boron-SR4?) to use keytool from the Linux CLI?

--Colin


On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>





_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev




Ryan Goulding <ryandgoulding@...>
 

Please let us know if there is anything else we can do to help.  I know that most of those karaf CLI commands were designed to be quite modular (thanks Moh), so we should be able to port them back in if absolutely necessary (w/ the security caveats surrounding what we discussed in the sync).  Reach out if you are still running into show stoppers and we will do our best to help.

Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 1:08 PM, Colin Dixon <colin@...> wrote:
We're testing things internally to make sure this all works the way we think it does. My guess is that this will get us over the hump, but either Luis or I will follow up if not.

Thanks,
--Colin


On Thu, Apr 27, 2017 at 1:06 PM, Ryan Goulding <ryandgoulding@...> wrote:
Confirmed here as well:

ryan@ubuntu:~/Desktop/distribution-karaf-0.5.3-Boron-SR3$ curl -u admin:admin -X POST -v http://localhost:8181/restconf/operations/aaa-cert-rpc:getODLCertificate
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8181 (#0)
* Server auth using Basic with user 'admin'
> POST /restconf/operations/aaa-cert-rpc:getODLCertificate HTTP/1.1
> Host: localhost:8181
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.47.0
> Accept: */*
< HTTP/1.1 200 OK
< Set-Cookie: JSESSIONID=c68vb1yxkgge1de3149bg89f4;Path=/restconf
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: rememberMe=deleteMe; Path=/restconf; Max-Age=0; Expires=Wed, 26-Apr-2017 17:05:02 GMT
< Content-Type: application/yang.operation+json
< Transfer-Encoding: chunked
< Server: Jetty(8.1.19.v20160209)
* Connection #0 to host localhost left intact
{"output":{"odl-cert":"MIICKjCCAZOgAwIBAgIFAMJ8aK8wDQYJKoZIhvcNAQEFBQAwWTEMMAoGA1UEAwwDT0RMMQwwCgYDVQQLDANEZXYxGDAWBgNVBAoMD0xpbnV4Rm91bmRhdGlvbjEUMBIGA1UEBwwLUUMgTW9udHJlYWwxCzAJBgNVBAYTAkNBMB4XDTE3MDQyNzE3MDQ1NFoXDTE4MDQyNzE3MDQ1NFowWTEMMAoGA1UEAwwDT0RMMQwwCgYDVQQLDANEZXYxGDAWBgNVBAoMD0xpbnV4Rm91bmRhdGlvbjEUMBIGA1UEBwwLUUMgTW9udHJlYWwxCzAJBgNVBAYTAkNBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCc0BBRpaAESyUD9PRTbpS3Qx39EIt3SvZKNqw9RnUes3h7AVaBIImbjpAkCVRYrM+e5f9l2kKraTbbSf2XBvS8GeyvGpTBONAgr/R1F6i1F10Pyw3kmUKjQu7/9kMa9M/9fnNREOvIO4hOwbUvLNeU9cjNOkpXsZRC/JDVZ9RpiQIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAEOBewJgTHHdUMAG7H1yauAPKW1adKtgh1+hdasQVFz0QdzoraY8JHpffJguTB4cX0zaAen4rF5bbrY9I4KNGajrUND8WsjZ8BSOeGyX0i600ZCZxztYT2ETDKZPoWoKwONaJbdqbAuvD8RdPIW5kddZi2tOhNIsLh74NaQGMShj"}}ryan@ubuntu:~/Desktop/distribution-karaf-0.5.3-Boron-SR3$ 

Are we good with this?  I.e., can you use RPC(s) instead of CLI commands?  Trying to be helpful here :).

Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 1:01 PM, Luis Gomez <ecelgp@...> wrote:
Thanks Mohamed, it works in Boron with your suggestion.

So what happens is that in Boron both <use-config> and <use-mdsal> are set to false by default and as a minimum you need to set the first to true for the feature to work. In Carbon both are set to true by default so the feature works out-of-the-box.

BR/Luis


On Apr 27, 2017, at 9:37 AM, Mohamed ElSerngawy <melserngawy@...> wrote:

Hi Luis,

I test the aa-cert RPCs with Boron and it works fine, did u change the aaa-cert-config.xml file ? I guess you may missed that. basically you need to change the <use-config> to true if you want to use keystore files and change <use-mdsal> true if you want to store  the keystores in mdsal. Then don't forget to restart karaf. check the wiki for more info


Hi Colin,

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
yes, just after installing the aaa-cert feature and changing the aaa-cert-config the keystore will be created. You can also use the java keytool commands to create the keystore instead. Moreover, If you wish to use a pre-created keystores signed by CA just copy those files to  directory configuration/ssl/ and change the aaa-cert-config.xml <use-config> to true  odl will use those files

2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)
use the RPCs to do this.

BR

On Thu, Apr 27, 2017 at 11:46 AM, Colin Dixon <colin@...> wrote:
That's a link to a patch in carbon, not boron. Is that to say the functionality is broken in Boron-SR3? If so, we need to figure out if there's a work-around and if so, document it in the Boron-SR3 release notes.

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)

I _think_ those are the only CLI commands we removed. It appears as though the replacement for 1.) is just feature:install odl-aaa-cert which will create the keystores automatically now.

It's less clear what the replacement to 2.) is. It appears as though the RPCs which should replace them throw NPEs. Is the workaround until we fix that (in Boron-SR4?) to use keytool from the Linux CLI?

--Colin


On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>





_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev





Luis Gomez
 

Mohamed, another thing I would like to confirm with you is that OVSDB SSL can use mdsal storage for cluster deployments but OpenFlow SSL cannot use mdsal yet, right?

BR/Luis


On Apr 27, 2017, at 9:37 AM, Mohamed ElSerngawy <melserngawy@...> wrote:

Hi Luis,

I test the aa-cert RPCs with Boron and it works fine, did u change the aaa-cert-config.xml file ? I guess you may missed that. basically you need to change the <use-config> to true if you want to use keystore files and change <use-mdsal> true if you want to store  the keystores in mdsal. Then don't forget to restart karaf. check the wiki for more info


Hi Colin,

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
yes, just after installing the aaa-cert feature and changing the aaa-cert-config the keystore will be created. You can also use the java keytool commands to create the keystore instead. Moreover, If you wish to use a pre-created keystores signed by CA just copy those files to  directory configuration/ssl/ and change the aaa-cert-config.xml <use-config> to true  odl will use those files

2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)
use the RPCs to do this.

BR

On Thu, Apr 27, 2017 at 11:46 AM, Colin Dixon <colin@...> wrote:
That's a link to a patch in carbon, not boron. Is that to say the functionality is broken in Boron-SR3? If so, we need to figure out if there's a work-around and if so, document it in the Boron-SR3 release notes.

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)

I _think_ those are the only CLI commands we removed. It appears as though the replacement for 1.) is just feature:install odl-aaa-cert which will create the keystores automatically now.

It's less clear what the replacement to 2.) is. It appears as though the RPCs which should replace them throw NPEs. Is the workaround until we fix that (in Boron-SR4?) to use keytool from the Linux CLI?

--Colin


On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>





Luis Gomez
 

Thanks Ryan, so far I think we are good, I will let you know otherwise.

On Apr 27, 2017, at 10:12 AM, Ryan Goulding <ryandgoulding@...> wrote:

Please let us know if there is anything else we can do to help.  I know that most of those karaf CLI commands were designed to be quite modular (thanks Moh), so we should be able to port them back in if absolutely necessary (w/ the security caveats surrounding what we discussed in the sync).  Reach out if you are still running into show stoppers and we will do our best to help.

Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 1:08 PM, Colin Dixon <colin@...> wrote:
We're testing things internally to make sure this all works the way we think it does. My guess is that this will get us over the hump, but either Luis or I will follow up if not.

Thanks,
--Colin


On Thu, Apr 27, 2017 at 1:06 PM, Ryan Goulding <ryandgoulding@...> wrote:
Confirmed here as well:

ryan@ubuntu:~/Desktop/distribution-karaf-0.5.3-Boron-SR3$ curl -u admin:admin -X POST -v http://localhost:8181/restconf/operations/aaa-cert-rpc:getODLCertificate
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8181 (#0)
* Server auth using Basic with user 'admin'
> POST /restconf/operations/aaa-cert-rpc:getODLCertificate HTTP/1.1
> Host: localhost:8181
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.47.0
> Accept: */*
< HTTP/1.1 200 OK
< Set-Cookie: JSESSIONID=c68vb1yxkgge1de3149bg89f4;Path=/restconf
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: rememberMe=deleteMe; Path=/restconf; Max-Age=0; Expires=Wed, 26-Apr-2017 17:05:02 GMT
< Content-Type: application/yang.operation+json
< Transfer-Encoding: chunked
< Server: Jetty(8.1.19.v20160209)
* Connection #0 to host localhost left intact
{"output":{"odl-cert":"MIICKjCCAZOgAwIBAgIFAMJ8aK8wDQYJKoZIhvcNAQEFBQAwWTEMMAoGA1UEAwwDT0RMMQwwCgYDVQQLDANEZXYxGDAWBgNVBAoMD0xpbnV4Rm91bmRhdGlvbjEUMBIGA1UEBwwLUUMgTW9udHJlYWwxCzAJBgNVBAYTAkNBMB4XDTE3MDQyNzE3MDQ1NFoXDTE4MDQyNzE3MDQ1NFowWTEMMAoGA1UEAwwDT0RMMQwwCgYDVQQLDANEZXYxGDAWBgNVBAoMD0xpbnV4Rm91bmRhdGlvbjEUMBIGA1UEBwwLUUMgTW9udHJlYWwxCzAJBgNVBAYTAkNBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCc0BBRpaAESyUD9PRTbpS3Qx39EIt3SvZKNqw9RnUes3h7AVaBIImbjpAkCVRYrM+e5f9l2kKraTbbSf2XBvS8GeyvGpTBONAgr/R1F6i1F10Pyw3kmUKjQu7/9kMa9M/9fnNREOvIO4hOwbUvLNeU9cjNOkpXsZRC/JDVZ9RpiQIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAEOBewJgTHHdUMAG7H1yauAPKW1adKtgh1+hdasQVFz0QdzoraY8JHpffJguTB4cX0zaAen4rF5bbrY9I4KNGajrUND8WsjZ8BSOeGyX0i600ZCZxztYT2ETDKZPoWoKwONaJbdqbAuvD8RdPIW5kddZi2tOhNIsLh74NaQGMShj"}}ryan@ubuntu:~/Desktop/distribution-karaf-0.5.3-Boron-SR3$ 

Are we good with this?  I.e., can you use RPC(s) instead of CLI commands?  Trying to be helpful here :).

Regards,

Ryan Goulding

On Thu, Apr 27, 2017 at 1:01 PM, Luis Gomez <ecelgp@...> wrote:
Thanks Mohamed, it works in Boron with your suggestion.

So what happens is that in Boron both <use-config> and <use-mdsal> are set to false by default and as a minimum you need to set the first to true for the feature to work. In Carbon both are set to true by default so the feature works out-of-the-box.

BR/Luis


On Apr 27, 2017, at 9:37 AM, Mohamed ElSerngawy <melserngawy@...> wrote:

Hi Luis,

I test the aa-cert RPCs with Boron and it works fine, did u change the aaa-cert-config.xml file ? I guess you may missed that. basically you need to change the <use-config> to true if you want to use keystore files and change <use-mdsal> true if you want to store  the keystores in mdsal. Then don't forget to restart karaf. check the wiki for more info


Hi Colin,

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
yes, just after installing the aaa-cert feature and changing the aaa-cert-config the keystore will be created. You can also use the java keytool commands to create the keystore instead. Moreover, If you wish to use a pre-created keystores signed by CA just copy those files to  directory configuration/ssl/ and change the aaa-cert-config.xml <use-config> to true  odl will use those files

2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)
use the RPCs to do this.

BR

On Thu, Apr 27, 2017 at 11:46 AM, Colin Dixon <colin@...> wrote:
That's a link to a patch in carbon, not boron. Is that to say the functionality is broken in Boron-SR3? If so, we need to figure out if there's a work-around and if so, document it in the Boron-SR3 release notes.

Can we get documentation for how somebody is supposed to:
1.) create the ODK keystore and trust keystore (replacing gen-odl-ks and gen-trust-ks)
2.) add a certificate to the ODL and turst keystores (replacing add-odl-cert and add-trust-cert)

I _think_ those are the only CLI commands we removed. It appears as though the replacement for 1.) is just feature:install odl-aaa-cert which will create the keystores automatically now.

It's less clear what the replacement to 2.) is. It appears as though the RPCs which should replace them throw NPEs. Is the workaround until we fix that (in Boron-SR4?) to use keytool from the Linux CLI?

--Colin


On Thu, Apr 27, 2017 at 9:34 AM, Mohamed ElSerngawy <melserngawy@...> wrote:
Hi Luis,

1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate 

This issue for Boron release it has beed fixed by patch [0]. so please try again and let me know if it still there.

2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?

For Carbon, The keystores stored at MD-SAL not as files OR if you will change the config to store the keystores as files, it will be under configuration/ssl/ . I guess Those files are created by the unit Test classes.

BR 


On Thu, Apr 27, 2017 at 9:11 AM, Colin Dixon <colin@...> wrote:
Do we have an idea of what the implications of just reverting that one patch are? Is it likely to work?

--Colin

On Wed, Apr 26, 2017 at 11:11 PM Jamo Luhrsen <jluhrsen@...> wrote:
btw, I was also trying to help get a broken AAA CSIT job working and ran in to some
troubles similar symptoms [0] to what Luis is reporting (500/NPE). Luis is playing with
cert stuff, and my work was in user/domain auth.

anyway, wondering if something fundamental is broken?

JamO

[0] https://lists.opendaylight.org/pipermail/aaa-dev/2017-April/001280.html



On 04/26/2017 06:21 PM, Luis Gomez wrote:
> hi guys, I just tested old-aaa-cert feature and couple of things:
>
> 1) it does not work in Boron, I get 500 Server error + NPE [1] when I try: POST /restconf/operations/aaa-cert-rpc:getODLCertificate
>
> 2) When I try in carbon I see 2 store files: ctl.jks, truststore.jks are created under ~/temp folder. Is it possible to change the path for these files?
>
>
> [1] NPE
>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
>         <title>Error 500 Server Error</title>
>     </head>
>     <body>
>         <h2>HTTP ERROR 500</h2>
>         <p>Problem accessing /restconf/operations/aaa-cert-rpc:getODLCertificate. Reason:
>
>             <pre>    Server Error</pre>
>         </p>
>         <h3>Caused by:</h3>
>         <pre>java.lang.NullPointerException
>       at org.opendaylight.aaa.cert.impl.AaaCertRpcServiceImpl.getODLCertificate(AaaCertRpcServiceImpl.java:92)
>       at org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithoutInput.invokeOn(RpcMethodInvokerWithoutInput.java:30)
>       at org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
>       at org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:177)
>       at org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
>       at Proxye69c1788_e30d_4fd8_8d29_f7f08932a9e7.invokeRpc(Unknown Source)
>       at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:506)
>       at org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:464)
>       at org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:83)
>       at org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at java.lang.reflect.Method.invoke(Method.java:498)
>       at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>       at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
>       at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>       at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
>       at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>       at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
>       at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381)
>       at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
>       at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>       at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>       at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
>       at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:256)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.opendaylight.aaa.filterchain.filters.CustomFilterAdapter.doFilter(CustomFilterAdapter.java:85)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
>       at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>       at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>       at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>       at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>       at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>       at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>       at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1478)
>       at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>       at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>       at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>       at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>       at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
>       at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
>       at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>       at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>       at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>       at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
>       at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>       at org.eclipse.jetty.server.Server.handle(Server.java:370)
>       at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>       at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
>       at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
>       at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
>       at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
>       at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>       at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>       at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>       at java.lang.Thread.run(Thread.java:745)
>
>
>
>
>
>> On Apr 26, 2017, at 12:50 PM, Mohamed ElSerngawy <melserngawy@...> wrote:
>>
>> Hi Colin,
>>
>> You are not suppose to use them after the changes that we made in the patch. Basically these functionalities were there because of the keystores need to be generated after starting ODL. But now, the keystore will be created once you install the aaa-cert feature. keeping this functionalities could make a serious security thread.
>>
>> BR
>>
>> On Wed, Apr 26, 2017 at 3:40 PM, Colin Dixon <colin@...> wrote:
>> Putting the argument about what should go in an SR aside for the moment, is there a straightforward way to access the functionality that was provided by the removed commands? Specifically gen-odl-ks and gen-trust-ks?
>>
>> --Colin
>>
>> On Wed, Apr 26, 2017 at 3:15 PM Ryan Goulding <ryandgoulding@...> wrote:
>> which is probably not in the spirit of SRs
>>
>> This was done for both usability and security purposes, as I explained via Skype already.  The security advantages alone make it justifiable IMHO.
>>
>>  While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.j
>>
>> This isn't a feature, it is CLI.
>>
>>  This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Yes, if you look at the bug actually, a member from your team commented on it [0] so I'd argue that it was at least somewhat well known ;).  Reverting it shouldn't be particularly hard, but it could open you open to some security issues in your downstream distro!
>>
>> Regards,
>>
>> Ryan Goulding
>>
>> [0] https://bugs.opendaylight.org/show_bug.cgi?id=7774
>>
>> On Wed, Apr 26, 2017 at 3:03 PM, Colin Dixon <colin@...> wrote:
>> So, in some downstream testing at Brocade we found that the AAA CLI commands were changed somewhat drastically between Boron-SR2 and Boron-SR3, which is probably not in the spirit of SRs. While we're somewhat less strict about adding features in SRs. Taking them out without a lot of warning and notice is pretty much the definition of what we try to never do in SRs.
>>
>> That being said, we're trying to make the best of it and looking for help in understanding how to get the functionality we rely on from AAA back in Boron-SR3.
>>
>> This patch seems to be the issue:
>> https://git.opendaylight.org/gerrit/#/c/51649/
>>
>> Is there somebody that can comment on how we might recover the functionality that used to be provided by the gen-odl-ks and gen-trust-ks CLI commands? Would simply reverting that patch work or would it break other things as well?
>>
>> Thanks,
>> --Colin
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>>
>>
>>
>> _______________________________________________
>> aaa-dev mailing list
>> aaa-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>
> _______________________________________________
> aaa-dev mailing list
> aaa-dev@...
> https://lists.opendaylight.org/mailman/listinfo/aaa-dev
>





_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev