nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henk Reder <h...@yetanalytics.com>
Subject Re: Issue securing nifi with ca-server.
Date Tue, 05 Jun 2018 16:39:23 GMT
Hey Peter!

in response to this
<http://mail-archives.apache.org/mod_mbox/nifi-dev/201806.mbox/raw/%3CCALj3mbA0Ny7zMH66vrMSyp+7Fax490YAjkiwV5-Vc5cB9Hjm_g@mail.gmail.com%3E/1>
.

Thanks for being quick on your response. I added that -c <ca-hostname>
parameter to the CA server setup, same issue occurs.
That "&" is actually an artifact of linux, it just means "run whatever this
line is on its own thread." I verified that it wasn't polluting the
arguments.
I also removed the --dn option from the server configuration and the issue
was consistent, response is still a 500.

I'm thinking a rollback to 1.5.0 should fix this, but it would appear that
whatever changes happened in the transition between versions broke that
existing configuration.

Any additional ideas or should I go ahead and roll it back?

Thanks again,
Henk


On Mon, Jun 4, 2018 at 8:34 PM, Henk Reder <henk@yetanalytics.com> wrote:

> Hello!
>
> My names Henk. I'm a web developer working on getting a nifi instance
> setup for some integrations.
>
> Long story short, I setup this nifi deployment configuration back when
> 1.5.0 was the latest version. Now that its 1.6.0 everything works!
> ...except one thing.
>
> I'm currently using tls-toolkit to setup each nodes identity in the
> cluster. In order to do this, I've followed the guidelines from this post
> <https://pierrevillard.com/2016/11/29/apache-nifi-1-1-0-secured-cluster-setup/>
back
> from 2016. heres a brief overview of my previously working configuration.
>
> *CA serverside:*
>
> <download tls-toolkit>
> <setup a linux-user>
> runuser -l <linux-user> -c '/home/nifica/bin/tls-toolkit.sh server -t
> <secret-token> -D CN=<ca-hostname>,OU=NIFI&'
>
> *Nifi-client side:*
>
> <download nifi>
> <download tls-toolkit>
> ./nifi-toolkit/bin/tls-toolkit.sh client -c <ca-hostname> -t
> <secret-token> --subjectAlternativeNames '<node-ip>,<node-hostname>'
-D
> 'CN=<node-hostname>,OU=NIFI' -T PKCS12
>
> I expect the actual certs and json config to comeback after the call to
> the tls-toolkit server. I can verify the request is going through but I get
> these obtuse messages that tell me very little.
>
>
>
> *Nifi-client side: *
> 2018/06/05 00:23:43 INFO [main] org.apache.nifi.toolkit.tls.
> service.client.TlsCertificateAuthorityClient: Requesting new certificate
> from <ca-hostname>:8443
> 2018/06/05 00:23:44 INFO [main] org.apache.nifi.toolkit.tls.
> service.client.TlsCertificateSigningRequestPerformer: Requesting
> certificate with dn CN=<hostname>,OU=NIFI from <ca-hostname>:8443
> Service client error: Received response code 500 with payload
>
> *CA serverside: *
>
> 2018/06/04 22:55:50 WARN [qtp1108924067-13] org.eclipse.jetty.server.HttpChannel:
> /
> javax.servlet.ServletException: Server error
>         at org.apache.nifi.toolkit.tls.service.server.
> TlsCertificateAuthorityServiceHandler.handle(
> TlsCertificateAuthorityServiceHandler.java:99)
>         at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> HandlerWrapper.java:132)
>         at org.eclipse.jetty.server.Server.handle(Server.java:564)
>         at org.eclipse.jetty.server.HttpChannel.handle(
> HttpChannel.java:369)
>         at org.eclipse.jetty.server.HttpConnection.onFillable(
> HttpConnection.java:251)
>         at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(
> AbstractConnection.java:279)
>         at org.eclipse.jetty.io.FillInterest.fillable(
> FillInterest.java:110)
>         at org.eclipse.jetty.io.ssl.SslConnection.onFillable(
> SslConnection.java:258)
>         at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(
> SslConnection.java:147)
>         at org.eclipse.jetty.io.FillInterest.fillable(
> FillInterest.java:110)
>         at org.eclipse.jetty.io.ChannelEndPoint$2.run(
> ChannelEndPoint.java:124)
>         at org.eclipse.jetty.util.thread.Invocable.invokePreferred(
> Invocable.java:122)
>         at org.eclipse.jetty.util.thread.strategy.
> ExecutingExecutionStrategy.invoke(ExecutingExecutionStrategy.java:58)
>         at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.
> produceConsume(ExecuteProduceConsume.java:201)
>         at org.eclipse.jetty.util.thread.strategy.
> ExecuteProduceConsume.run(ExecuteProduceConsume.java:133)
>         at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
> QueuedThreadPool.java:672)
>         at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(
> QueuedThreadPool.java:590)
>         at java.lang.Thread.run(Thread.java:748)
> 2018/06/04 22:55:50 WARN [qtp1108924067-13] org.eclipse.jetty.server.
> HttpChannel:
> java.lang.IllegalStateException: Error already set
>         at org.eclipse.jetty.server.HttpChannelState.onError(
> HttpChannelState.java:743)
>         at org.eclipse.jetty.server.HttpChannel.handleException(
> HttpChannel.java:514)
>         at org.eclipse.jetty.server.HttpChannelOverHttp.handleException(
> HttpChannelOverHttp.java:463)
>         at org.eclipse.jetty.server.HttpChannel.handle(
> HttpChannel.java:448)
>         at org.eclipse.jetty.server.HttpConnection.onFillable(
> HttpConnection.java:251)
>         at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(
> AbstractConnection.java:279)
>         at org.eclipse.jetty.io.FillInterest.fillable(
> FillInterest.java:110)
>         at org.eclipse.jetty.io.ssl.SslConnection.onFillable(
> SslConnection.java:258)
>         at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(
> SslConnection.java:147)
>         at org.eclipse.jetty.io.FillInterest.fillable(
> FillInterest.java:110)
>         at org.eclipse.jetty.io.ChannelEndPoint$2.run(
> ChannelEndPoint.java:124)
>         at org.eclipse.jetty.util.thread.Invocable.invokePreferred(
> Invocable.java:122)
>         at org.eclipse.jetty.util.thread.strategy.
> ExecutingExecutionStrategy.invoke(ExecutingExecutionStrategy.java:58)
>         at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.
> produceConsume(ExecuteProduceConsume.java:201)
>         at org.eclipse.jetty.util.thread.strategy.
> ExecuteProduceConsume.run(ExecuteProduceConsume.java:133)
>         at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
> QueuedThreadPool.java:672)
>         at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(
> QueuedThreadPool.java:590)
>         at java.lang.Thread.run(Thread.java:748)
>
>
> Seeing as this code was working before, my first assumption is the problem
> has something to do with some new undocumented behaviors. I fooled around
> with the parameters for a bit and got very similar results, and a lot of
> research and digging has left me scratching my head. I know its a 500, and
> the CA server is the one throwing the exception, but I can't quite figure
> out what changed and why its behaving this way. There's also no clear
> indicator of what's causing the issue. I can see a callback being passed
> down the stack but no message hinting at bad parameters or anything like
> that.
>
> If it helps, this is the java version I'm running on my machine:
>
>
> openjdk version "1.8.0_171"
> OpenJDK Runtime Environment (build 1.8.0_171-b10)
> OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode)
>
> If you have any further questions, please don't hesitate to ask. Thanks
> for your time!
> Henk
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message