Re: ElasticSearchClientServiceImpl not working for secured ElasticSearch

[Peter Moberg]

Think I might have found the issue. Will report tonight.

Mike, please don’t spend any time debugging this because I think it might be an 
issue on my side. Appreciate all the help so far.

Thanks,

Peter
On Oct 18, 2019, 2:21 PM -0500, Peter Moberg , wrote:
> Here it is:
>
>
> 2019-10-18 18:47:02,548 ERROR [Timer-Driven Process Thread-7] 
> o.a.n.processors.standard.LookupRecord 
> LookupRecord[id=df596687-016d-1000--65536eb2] Failed to process 
> StandardFlowFileRecord[uuid=64d0d1f4-1960-4a91-9394-39edc9d6c9c7,claim=StandardContentClaim
>  [resourceClaim=StandardResourceClaim[id=1571410822200-1, container=default, 
> section=1], offset=7180, 
> length=20],offset=0,name=64d0d1f4-1960-4a91-9394-39edc9d6c9c7,size=20]: 
> org.apache.nifi.processor.exception.ProcessException: Failed to lookup 
> coordinates {key=test} in Lookup Service
> org.apache.nifi.processor.exception.ProcessException: Failed to lookup 
> coordinates {key=test} in Lookup Service
> at 
> org.apache.nifi.processors.standard.LookupRecord.route(LookupRecord.java:300)
> at 
> org.apache.nifi.processors.standard.LookupRecord.route(LookupRecord.java:68)
> at 
> org.apache.nifi.processors.standard.AbstractRouteRecord$1.process(AbstractRouteRecord.java:134)
> at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:2212)
> at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:2180)
> at 
> org.apache.nifi.processors.standard.AbstractRouteRecord.onTrigger(AbstractRouteRecord.java:121)
> at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1162)
> at 
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:209)
> at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:117)
> at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.nifi.lookup.LookupFailureException: 
> org.apache.nifi.lookup.LookupFailureException: 
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at 
> org.apache.nifi.elasticsearch.ElasticSearchLookupService.lookup(ElasticSearchLookupService.java:175)
> at sun.reflect.GeneratedMethodAccessor746.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.nifi.controller.service.StandardControllerServiceInvocationHandler.invoke(StandardControllerServiceInvocationHandler.java:87)
> at com.sun.proxy.$Proxy136.lookup(Unknown Source)
> at 
> org.apache.nifi.processors.standard.LookupRecord.route(LookupRecord.java:298)
> ... 17 common frames omitted
> Caused by: org.apache.nifi.lookup.LookupFailureException: 
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at 
> org.apache.nifi.elasticsearch.ElasticSearchLookupService.getByQuery(ElasticSearchLookupService.java:288)
> at 
> org.apache.nifi.elasticsearch.ElasticSearchLookupService.lookup(ElasticSearchLookupService.java:169)
> ... 23 common frames omitted
> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529)
> at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
> at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
> at org.apache.http.nio.reactor.ssl.SSLIOSession.doWrap(SSLIOSession.java:265)
> at 
> org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:305)
> at 
> org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:509)
> at 
> org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:120)
> at 
> org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
> at 
> org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
> at 
> 

Re: Curious about Best Practices for Deployment of Workflows

[Andy LoPresto]

Ken, 

There are a lot of disjoint resources that discuss some of these concepts, but 
they are not well-organized at the moment. I would recommend Kevin Doran’s 
presentation at Dataworks Summit 2018 [1] as a good starting point, 
specifically including some activity hooks which can automate much of the 
process you describe. Drew Lim has also recorded some videos showing features 
and workflows (I separate workflow [“the process of performing some manual 
activities against the NiFi ecosystem applications”] from dataflow [“the graph 
of components which runs within NiFi and ingests, routes, transforms, and 
persists data”]) [2] (scroll down to “Videos”). 

If others can chime in with their resources as well, we can collect these into 
a more useful format and hopefully enable more people to use these tools 
productively. 

[1] https://dataworkssummit.com/san-jose-2018/session/sdlc-with-apache-nifi/ 

[2] https://nifi.apache.org/registry.html 



Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Oct 18, 2019, at 12:53 PM, Ken Swanson  wrote:
> 
> Hi all,
> 
> My group is getting started with NiFi and I'm hoping to draw on people's 
> experience. I was curious if there were any best practices for NiFi when 
> deploying workflows. When I deploy new code to production, there's often pull 
> requests, code review, and then CI/CD to actually put it in production. Is 
> there anything similar for workflows, or do people have solutions that they 
> use?
> 
> I'd love it if there was a way for someone to make a local change to a 
> workflow/process group, push that up to the registry, and then a reviewer see 
> a diff of the change, approve it, and then it get automatically put onto 
> master. Is this something people tend to do with NiFi?
> 
> -Ken

Curious about Best Practices for Deployment of Workflows

[Ken Swanson]

Hi all,

My group is getting started with NiFi and I'm hoping to draw on people's
experience. I was curious if there were any best practices for NiFi when
deploying workflows. When I deploy new code to production, there's often
pull requests, code review, and then CI/CD to actually put it in
production. Is there anything similar for workflows, or do people have
solutions that they use?

I'd love it if there was a way for someone to make a local change to a
workflow/process group, push that up to the registry, and then a reviewer
see a diff of the change, approve it, and then it get automatically put
onto master. Is this something people tend to do with NiFi?

-Ken

Re: ElasticSearchClientServiceImpl not working for secured ElasticSearch

[Peter Moberg]

Here it is:


2019-10-18 18:47:02,548 ERROR [Timer-Driven Process Thread-7] 
o.a.n.processors.standard.LookupRecord 
LookupRecord[id=df596687-016d-1000--65536eb2] Failed to process 
StandardFlowFileRecord[uuid=64d0d1f4-1960-4a91-9394-39edc9d6c9c7,claim=StandardContentClaim
 [resourceClaim=StandardResourceClaim[id=1571410822200-1, container=default, 
section=1], offset=7180, 
length=20],offset=0,name=64d0d1f4-1960-4a91-9394-39edc9d6c9c7,size=20]: 
org.apache.nifi.processor.exception.ProcessException: Failed to lookup 
coordinates {key=test} in Lookup Service
org.apache.nifi.processor.exception.ProcessException: Failed to lookup 
coordinates {key=test} in Lookup Service
at org.apache.nifi.processors.standard.LookupRecord.route(LookupRecord.java:300)
at org.apache.nifi.processors.standard.LookupRecord.route(LookupRecord.java:68)
at 
org.apache.nifi.processors.standard.AbstractRouteRecord$1.process(AbstractRouteRecord.java:134)
at 
org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:2212)
at 
org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:2180)
at 
org.apache.nifi.processors.standard.AbstractRouteRecord.onTrigger(AbstractRouteRecord.java:121)
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1162)
at 
org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:209)
at 
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:117)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.nifi.lookup.LookupFailureException: 
org.apache.nifi.lookup.LookupFailureException: 
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at 
org.apache.nifi.elasticsearch.ElasticSearchLookupService.lookup(ElasticSearchLookupService.java:175)
at sun.reflect.GeneratedMethodAccessor746.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.nifi.controller.service.StandardControllerServiceInvocationHandler.invoke(StandardControllerServiceInvocationHandler.java:87)
at com.sun.proxy.$Proxy136.lookup(Unknown Source)
at org.apache.nifi.processors.standard.LookupRecord.route(LookupRecord.java:298)
... 17 common frames omitted
Caused by: org.apache.nifi.lookup.LookupFailureException: 
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at 
org.apache.nifi.elasticsearch.ElasticSearchLookupService.getByQuery(ElasticSearchLookupService.java:288)
at 
org.apache.nifi.elasticsearch.ElasticSearchLookupService.lookup(ElasticSearchLookupService.java:169)
... 23 common frames omitted
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doWrap(SSLIOSession.java:265)
at 
org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:305)
at 
org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:509)
at 
org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:120)
at 
org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
at 
org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
at 
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588)
... 1 common frames omitted
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
at 

Re: ElasticSearchClientServiceImpl not working for secured ElasticSearch

[Mike Thomsen]

Can you share the stacktrace from the logs?

On Fri, Oct 18, 2019 at 2:38 PM Peter Moberg  wrote:

> Mike,
>
> The SSLContextService only had the Trust store configured. I think I seen
> that ticket before but didn’t pay attention to the fact it wasn’t merged in
> to the code I am running.
>
> However, I configured the service to have a KeyStore now but I am getting
> the same errors…
>
> Thanks,
>
> Peter
> On Oct 18, 2019, 11:39 AM -0500, Mike Thomsen ,
> wrote:
>
> Peter,
>
> Are you configuring the service as a trust-only configuration? If so,
> that's been addressed in the 1.10 which is due for release in the near(ish)
> future.
>
> https://issues.apache.org/jira/browse/NIFI-6228
>
> Thanks,
>
> Mike
>
> On Fri, Oct 18, 2019 at 11:06 AM Peter Moberg 
> wrote:
>
>> As a follow-up.
>>
>> On the Nifi node I am able to do a GET to Elastic Search using curl. I
>> specify the —cacert option giving it the self-signed root certificate.
>>
>> Of course, this isn’t using the TrustStore but I am able to use the
>> TrustStore if I use other ES processors… just not the
>> ElasticSearchClientServicesImpl.
>>
>> On Oct 18, 2019, 12:48 AM -0500, Peter Moberg ,
>> wrote:
>>
>> Hi Andy,
>>
>> thanks for your suggestions. Here is what I have tried so far (still no
>> luck).
>>
>> Connecting with openssl and viewing the certs it presents
>>
>> *openssl s_client -connect quickstart-es-http.es
>> -cluster -showcerts*
>>
>> If I then look inside the server cert I can find this
>>
>>
>>
>>
>>
>> *Server Cert: Issuer: OU = quickstart, CN = quickstart-http X509v3
>> Subject Alternative Name: DNS:quickstart-es-http.es
>> -cluster.es.local, DNS:quickstart-es-http,
>> DNS:quickstart-es-http.es -cluster.svc,
>> DNS:quickstart-es-http.es -cluster*
>>
>>
>> If I look in to the self-signed root cert I find this:
>>
>>
>> *Root Cert: Subject: OU = quickstart, CN = quickstart-http*
>>
>>
>> I now double check  my trust store to make sure the Root Cert is there.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Trust store content Your keystore contains 1 entry Alias name:
>> ca_elastic Creation date: Oct 16, 2019 Entry type: trustedCertEntry Owner:
>> CN=quickstart-http, OU=quickstart Issuer: CN=quickstart-http, OU=quickstart
>> Serial number: 5aa50b6806d2394fff6f98d2b7d4c287 Valid from: Fri Oct 11
>> 14:35:01 UTC 2019 until: Sat Oct 10 14:36:01 UTC 2020 Certificate
>> fingerprints: MD5: 1E:E3:33:13:EA:AC:B5:61:23:DE:2E:1A:D7:9C:AA:F0 SHA1:
>> 62:EC:5B:EB:32:6A:38:3D:6A:6B:F7:10:5A:DE:E6:F1:F0:5B:07:99 SHA256:
>> B4:B5:06:9C:50:5F:E8:A1:58:7C:C7:2C:37:52:2F:E0:CF:32:18:18:68:E4:C7:37:F8:82:B3:BC:61:EB:5B:CF
>> Signature algorithm name: SHA256withRSA Subject Public Key Algorithm:
>> 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19
>> Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2:
>> ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth
>> clientAuth ] #3: ObjectId: 2.5.29.15 Criticality=true KeyUsage [
>> DigitalSignature Key_CertSign ]*
>>
>> So everything looks Ok. But when I run the
>> ElasticSearchClientServicesImpl with a SSLContext pointing to my trust
>> store I still get the following output in the log.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine
>> problem at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at
>> sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) at
>> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330) at
>> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1633)
>> at
>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) at
>> sun.security.ssl.Handshaker$1.run(Handshaker.java:992) at
>> sun.security.ssl.Handshaker$1.run(Handshaker.java:989) at
>> java.security.AccessController.doPrivileged(Native Method) at
>> sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) at
>> org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:283)
>> at
>> org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:353)
>> ... 9 common frames omitted Caused by:
>> sun.security.validator.ValidatorException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
>> valid certification path to requested target at
>> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397) at
>> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
>> at sun.security.validator.Validator.validate(Validator.java:262) at
>> 

Re: Implementing a custom provenance reporting task

[Matt Burgess]

Tim,

The "secondary flow" issue is something I wanted to address as well,
so I decoupled the formatting of data from the transmission of that
data into a new paradigm/service I'm calling a RecordServiceSink. A
ReportingTask can use RecordServiceSink to allow the user to choose
where the reporting "records" are to go. I'm doing this work under
NIFI-6780 [1] and the PR is currently under review [2], so hopefully
it'll be coming soon to a NiFi near you :)

With this capability you could have a ProvenanceRecordReportingTask
for example, one that uses a RecordSinkService rather than strictly
site-to-site. My PR does include a SiteToSiteReportingRecordSink in
order to add feature parity in case such a
"ProvenanceRecordReportingTask" was implemented. If you use a
SiteToSiteReportingRecordSink with it, I'd expect that to be pretty
much the same as using the SiteToSiteProvenanceReportingTask. In your
case you'd want to add a RecordSinkService implementation for your own
in-house system, but in either case the reporting task itself would be
the same. I expect it would probably look similar to the current
SiteToSiteReportingTask in terms of code; the changes would be to get
the results into a RecordSet and call sendData() on the
RecordSinkService. With this we'd have a more generic reporting task
that anyone could use to get provenance data to any supported "record
sink"/target, without the need for a sub-flow, input port, and the
associated extraneous provenance events generated for that sub-flow.

I should mention there's also a DatabaseRecordSink (that uses a
DBCPConnectionPool controller service) in the PR as well, so there are
two initial possible sinks/destinations available. I'll follow those
up with a PrometheusRecordSink and perhaps some KafkaRecordSink
implementations as well.

Happy to discuss this more, and please feel free to look at the PR and
comment on it as you like, I'm always looking for feedback!

Regards,
Matt

[1] https://issues.apache.org/jira/browse/NIFI-6780
[2] https://github.com/apache/nifi/pull/3826

On Fri, Oct 18, 2019 at 1:50 PM Tim Dean  wrote:
>
> Thanks Mike,
>
> I understand what you are saying but I am really trying to avoid having a 
> secondary flow in NiFi if I can avoid it.
>
> It seems like NiFi was designed to allow this kind of custom reporting task 
> and that I should ideally be able to do this without using the NiFi-provided 
> S2S implementation if that doesn’t suit my needs.
>
> - Tim
>
> Sent from my iPhone
>
> > On Oct 18, 2019, at 12:36 PM, Mike Thomsen  wrote:
> >

Re: ElasticSearchClientServiceImpl not working for secured ElasticSearch

[Peter Moberg]

Mike,

The SSLContextService only had the Trust store configured. I think I seen that 
ticket before but didn’t pay attention to the fact it wasn’t merged in to the 
code I am running.

However, I configured the service to have a KeyStore now but I am getting the 
same errors…

Thanks,

Peter
On Oct 18, 2019, 11:39 AM -0500, Mike Thomsen , wrote:
> Peter,
>
> Are you configuring the service as a trust-only configuration? If so, that's 
> been addressed in the 1.10 which is due for release in the near(ish) future.
>
> https://issues.apache.org/jira/browse/NIFI-6228
>
> Thanks,
>
> Mike
>
> > On Fri, Oct 18, 2019 at 11:06 AM Peter Moberg  
> > wrote:
> > > As a follow-up.
> > >
> > > On the Nifi node I am able to do a GET to Elastic Search using curl. I 
> > > specify the —cacert option giving it the self-signed root certificate.
> > >
> > > Of course, this isn’t using the TrustStore but I am able to use the 
> > > TrustStore if I use other ES processors… just not the 
> > > ElasticSearchClientServicesImpl.
> > >
> > > On Oct 18, 2019, 12:48 AM -0500, Peter Moberg , 
> > > wrote:
> > > > Hi Andy,
> > > >
> > > > thanks for your suggestions. Here is what I have tried so far (still no 
> > > > luck).
> > > >
> > > > Connecting with openssl and viewing the certs it presents
> > > >
> > > > openssl s_client -connect quickstart-es-http.es-cluster -showcerts
> > > >
> > > > If I then look inside the server cert I can find this
> > > >
> > > > Server Cert:
> > > > Issuer: OU = quickstart, CN = quickstart-http
> > > >
> > > > X509v3 Subject Alternative Name:
> > > > DNS:quickstart-es-http.es-cluster.es.local, DNS:quickstart-es-http, 
> > > > DNS:quickstart-es-http.es-cluster.svc, DNS:quickstart-es-http.es-cluster
> > > >
> > > >
> > > > If I look in to the self-signed root cert I find this:
> > > >
> > > > Root Cert:
> > > > Subject: OU = quickstart, CN = quickstart-http
> > > >
> > > >
> > > > I now double check  my trust store to make sure the Root Cert is there.
> > > >
> > > > Trust store content
> > > > Your keystore contains 1 entry
> > > >
> > > > Alias name: ca_elastic
> > > > Creation date: Oct 16, 2019
> > > > Entry type: trustedCertEntry
> > > >
> > > > Owner: CN=quickstart-http, OU=quickstart
> > > > Issuer: CN=quickstart-http, OU=quickstart
> > > > Serial number: 5aa50b6806d2394fff6f98d2b7d4c287
> > > > Valid from: Fri Oct 11 14:35:01 UTC 2019 until: Sat Oct 10 14:36:01 UTC 
> > > > 2020
> > > > Certificate fingerprints:
> > > > MD5: 1E:E3:33:13:EA:AC:B5:61:23:DE:2E:1A:D7:9C:AA:F0
> > > > SHA1: 62:EC:5B:EB:32:6A:38:3D:6A:6B:F7:10:5A:DE:E6:F1:F0:5B:07:99
> > > > SHA256: 
> > > > B4:B5:06:9C:50:5F:E8:A1:58:7C:C7:2C:37:52:2F:E0:CF:32:18:18:68:E4:C7:37:F8:82:B3:BC:61:EB:5B:CF
> > > > Signature algorithm name: SHA256withRSA
> > > > Subject Public Key Algorithm: 2048-bit RSA key
> > > > Version: 3
> > > >
> > > > Extensions:
> > > >
> > > > #1: ObjectId: 2.5.29.19 Criticality=true
> > > > BasicConstraints:[
> > > > CA:true
> > > > PathLen:2147483647
> > > > ]
> > > >
> > > > #2: ObjectId: 2.5.29.37 Criticality=false
> > > > ExtendedKeyUsages [
> > > > serverAuth
> > > > clientAuth
> > > > ]
> > > >
> > > > #3: ObjectId: 2.5.29.15 Criticality=true
> > > > KeyUsage [
> > > > DigitalSignature
> > > > Key_CertSign
> > > > ]
> > > >
> > > > So everything looks Ok. But when I run the 
> > > > ElasticSearchClientServicesImpl with a SSLContext pointing to my trust 
> > > > store I still get the following output in the log.
> > > >
> > > > Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine 
> > > > problem
> > > > at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> > > > at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> > > > at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330)
> > > > at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
> > > > at 
> > > > sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1633)
> > > > at 
> > > > sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> > > > at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> > > > at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
> > > > at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
> > > > at java.security.AccessController.doPrivileged(Native Method)
> > > > at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
> > > > at 
> > > > org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:283)
> > > > at 
> > > > org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:353)
> > > > ... 9 common frames omitted
> > > > Caused by: sun.security.validator.ValidatorException: PKIX path 
> > > > building failed: 
> > > > sun.security.provider.certpath.SunCertPathBuilderException: unable to 
> > > > find valid certification path to requested target
> > > > at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
> > > > at 
> > > > 

Re: Implementing a custom provenance reporting task

[Tim Dean]

Thanks Mike,

I understand what you are saying but I am really trying to avoid having a 
secondary flow in NiFi if I can avoid it. 

It seems like NiFi was designed to allow this kind of custom reporting task and 
that I should ideally be able to do this without using the NiFi-provided S2S 
implementation if that doesn’t suit my needs.

- Tim

Sent from my iPhone

> On Oct 18, 2019, at 12:36 PM, Mike Thomsen  wrote:
> 

Re: Implementing a custom provenance reporting task

[Mike Thomsen]

I would recommend using the site to site task instead of your own because
it will give you a very scalable way to asynchronously handle your
provenance tracking. There's nothing preventing you from having the
tracking instance of NiFi be responsible for publishing the events to your
tracking system. A lot of people do this with Elastic and Kibana with very
good results.

On Fri, Oct 18, 2019 at 12:01 PM Tim Dean  wrote:

> I would like to implement some custom monitoring logic that captures
> certain information from the provenance repository. It would be similar in
> some ways to the existing SiteToSiteProvenanceReporting task, but it will
> not be sending information to another NiFi node but instead sending things
> to an in-house tracking service that we use.
>
> There is a little information about writing custom reporting tasks in the
> NiFi developer documentation, but it’s pretty limited in what it covers. I
> want to make sure I capture all the events that come in, and I want to be
> resilient to situations when the NiFi node is rebooted, or certain
> components are stopped temporarily, etc.
>
> To get an idea of how to best accomplish this I’ve been looking at the
> source code for SiteToSiteProvenanceReportingTask on GitHub. It appears to
> push a delegate a lot of the details of event capturing to the
> org.apache.nifi.reporting.util.provenance.ProvenanceEventConsumer class.
> I’ve poked around that class to see what it does, and I think I could use
> it In my own custom reporting class to make things easier. However, that
> class doesn’t seem to be documented publicly anywhere, and isn’t mentioned
> in the developer guide. I am concerned that it might be necessary to treat
> this as a private class that may change from release to release.
>
> How would you recommend that I proceed to create my own provenance event
> reporting task? Should I mimic SiteToSiteProvenanceReportingTask and built
> it on top of the ProvenanceEventConsumer class? Should I instead pull out
> the parts of ProvenanceEventConsumer that I need and create my own version
> of that class that I can control?
> Any other approaches I should consider instead of the path I’m heading
> down now?
>
>

Re: ElasticSearchClientServiceImpl not working for secured ElasticSearch

[Juan Pablo Gardella]

I have an issue to validate, reported at before:
http://apache-nifi.1125220.n5.nabble.com/Error-instantiating-template-on-cluster-The-specified-observer-identifier-already-exists-td12973.html

I reproduced it at apache nifi 1.5.0. I will try to check at nifi 1.9.2.
The template to load is near to 50MB.

Juan

On Fri, 18 Oct 2019 at 14:13, Joe Witt  wrote:

> is a daily effort at this point.  i am close to pushing first rc.  have
> been watching for stability on bug fixes.
>
> On Fri, Oct 18, 2019 at 1:10 PM Juan Pablo Gardella <
> gardellajuanpa...@gmail.com> wrote:
>
>> Any ETA for Nifi 1.10 release?
>>
>> On Fri, 18 Oct 2019 at 13:39, Mike Thomsen 
>> wrote:
>>
>>> Peter,
>>>
>>> Are you configuring the service as a trust-only configuration? If so,
>>> that's been addressed in the 1.10 which is due for release in the near(ish)
>>> future.
>>>
>>> https://issues.apache.org/jira/browse/NIFI-6228
>>>
>>> Thanks,
>>>
>>> Mike
>>>
>>> On Fri, Oct 18, 2019 at 11:06 AM Peter Moberg 
>>> wrote:
>>>
 As a follow-up.

 On the Nifi node I am able to do a GET to Elastic Search using curl. I
 specify the —cacert option giving it the self-signed root certificate.

 Of course, this isn’t using the TrustStore but I am able to use the
 TrustStore if I use other ES processors… just not the
 ElasticSearchClientServicesImpl.

 On Oct 18, 2019, 12:48 AM -0500, Peter Moberg ,
 wrote:

 Hi Andy,

 thanks for your suggestions. Here is what I have tried so far (still no
 luck).

 Connecting with openssl and viewing the certs it presents

 *openssl s_client -connect quickstart-es-http.es
 -cluster -showcerts*

 If I then look inside the server cert I can find this





 *Server Cert: Issuer: OU = quickstart, CN = quickstart-http X509v3
 Subject Alternative Name: DNS:quickstart-es-http.es
 -cluster.es.local, DNS:quickstart-es-http,
 DNS:quickstart-es-http.es -cluster.svc,
 DNS:quickstart-es-http.es -cluster*


 If I look in to the self-signed root cert I find this:


 *Root Cert: Subject: OU = quickstart, CN = quickstart-http*


 I now double check  my trust store to make sure the Root Cert is there.







































 *Trust store content Your keystore contains 1 entry Alias name:
 ca_elastic Creation date: Oct 16, 2019 Entry type: trustedCertEntry Owner:
 CN=quickstart-http, OU=quickstart Issuer: CN=quickstart-http, OU=quickstart
 Serial number: 5aa50b6806d2394fff6f98d2b7d4c287 Valid from: Fri Oct 11
 14:35:01 UTC 2019 until: Sat Oct 10 14:36:01 UTC 2020 Certificate
 fingerprints: MD5: 1E:E3:33:13:EA:AC:B5:61:23:DE:2E:1A:D7:9C:AA:F0 SHA1:
 62:EC:5B:EB:32:6A:38:3D:6A:6B:F7:10:5A:DE:E6:F1:F0:5B:07:99 SHA256:
 B4:B5:06:9C:50:5F:E8:A1:58:7C:C7:2C:37:52:2F:E0:CF:32:18:18:68:E4:C7:37:F8:82:B3:BC:61:EB:5B:CF
 Signature algorithm name: SHA256withRSA Subject Public Key Algorithm:
 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19
 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2:
 ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth
 clientAuth ] #3: ObjectId: 2.5.29.15 Criticality=true KeyUsage [
 DigitalSignature Key_CertSign ]*

 So everything looks Ok. But when I run the
 ElasticSearchClientServicesImpl with a SSLContext pointing to my trust
 store I still get the following output in the log.
























 *Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine
 problem at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at
 sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) at
 sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330) at
 sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) at
 sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1633)
 at
 sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
 at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) at
 sun.security.ssl.Handshaker$1.run(Handshaker.java:992) at
 sun.security.ssl.Handshaker$1.run(Handshaker.java:989) at
 java.security.AccessController.doPrivileged(Native Method) at
 sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) at
 org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:283)
 at
 org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:353)
 ... 9 common frames 

Re: ElasticSearchClientServiceImpl not working for secured ElasticSearch

[Joe Witt]

is a daily effort at this point.  i am close to pushing first rc.  have
been watching for stability on bug fixes.

On Fri, Oct 18, 2019 at 1:10 PM Juan Pablo Gardella <
gardellajuanpa...@gmail.com> wrote:

> Any ETA for Nifi 1.10 release?
>
> On Fri, 18 Oct 2019 at 13:39, Mike Thomsen  wrote:
>
>> Peter,
>>
>> Are you configuring the service as a trust-only configuration? If so,
>> that's been addressed in the 1.10 which is due for release in the near(ish)
>> future.
>>
>> https://issues.apache.org/jira/browse/NIFI-6228
>>
>> Thanks,
>>
>> Mike
>>
>> On Fri, Oct 18, 2019 at 11:06 AM Peter Moberg 
>> wrote:
>>
>>> As a follow-up.
>>>
>>> On the Nifi node I am able to do a GET to Elastic Search using curl. I
>>> specify the —cacert option giving it the self-signed root certificate.
>>>
>>> Of course, this isn’t using the TrustStore but I am able to use the
>>> TrustStore if I use other ES processors… just not the
>>> ElasticSearchClientServicesImpl.
>>>
>>> On Oct 18, 2019, 12:48 AM -0500, Peter Moberg ,
>>> wrote:
>>>
>>> Hi Andy,
>>>
>>> thanks for your suggestions. Here is what I have tried so far (still no
>>> luck).
>>>
>>> Connecting with openssl and viewing the certs it presents
>>>
>>> *openssl s_client -connect quickstart-es-http.es
>>> -cluster -showcerts*
>>>
>>> If I then look inside the server cert I can find this
>>>
>>>
>>>
>>>
>>>
>>> *Server Cert: Issuer: OU = quickstart, CN = quickstart-http X509v3
>>> Subject Alternative Name: DNS:quickstart-es-http.es
>>> -cluster.es.local, DNS:quickstart-es-http,
>>> DNS:quickstart-es-http.es -cluster.svc,
>>> DNS:quickstart-es-http.es -cluster*
>>>
>>>
>>> If I look in to the self-signed root cert I find this:
>>>
>>>
>>> *Root Cert: Subject: OU = quickstart, CN = quickstart-http*
>>>
>>>
>>> I now double check  my trust store to make sure the Root Cert is there.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Trust store content Your keystore contains 1 entry Alias name:
>>> ca_elastic Creation date: Oct 16, 2019 Entry type: trustedCertEntry Owner:
>>> CN=quickstart-http, OU=quickstart Issuer: CN=quickstart-http, OU=quickstart
>>> Serial number: 5aa50b6806d2394fff6f98d2b7d4c287 Valid from: Fri Oct 11
>>> 14:35:01 UTC 2019 until: Sat Oct 10 14:36:01 UTC 2020 Certificate
>>> fingerprints: MD5: 1E:E3:33:13:EA:AC:B5:61:23:DE:2E:1A:D7:9C:AA:F0 SHA1:
>>> 62:EC:5B:EB:32:6A:38:3D:6A:6B:F7:10:5A:DE:E6:F1:F0:5B:07:99 SHA256:
>>> B4:B5:06:9C:50:5F:E8:A1:58:7C:C7:2C:37:52:2F:E0:CF:32:18:18:68:E4:C7:37:F8:82:B3:BC:61:EB:5B:CF
>>> Signature algorithm name: SHA256withRSA Subject Public Key Algorithm:
>>> 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19
>>> Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2:
>>> ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth
>>> clientAuth ] #3: ObjectId: 2.5.29.15 Criticality=true KeyUsage [
>>> DigitalSignature Key_CertSign ]*
>>>
>>> So everything looks Ok. But when I run the
>>> ElasticSearchClientServicesImpl with a SSLContext pointing to my trust
>>> store I still get the following output in the log.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine
>>> problem at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at
>>> sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) at
>>> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330) at
>>> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) at
>>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1633)
>>> at
>>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) at
>>> sun.security.ssl.Handshaker$1.run(Handshaker.java:992) at
>>> sun.security.ssl.Handshaker$1.run(Handshaker.java:989) at
>>> java.security.AccessController.doPrivileged(Native Method) at
>>> sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) at
>>> org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:283)
>>> at
>>> org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:353)
>>> ... 9 common frames omitted Caused by:
>>> sun.security.validator.ValidatorException: PKIX path building failed:
>>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
>>> valid certification path to requested target at
>>> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397) at
>>> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
>>> at sun.security.validator.Validator.validate(Validator.java:262) at
>>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)

Re: ElasticSearchClientServiceImpl not working for secured ElasticSearch

[Juan Pablo Gardella]

Any ETA for Nifi 1.10 release?

On Fri, 18 Oct 2019 at 13:39, Mike Thomsen  wrote:

> Peter,
>
> Are you configuring the service as a trust-only configuration? If so,
> that's been addressed in the 1.10 which is due for release in the near(ish)
> future.
>
> https://issues.apache.org/jira/browse/NIFI-6228
>
> Thanks,
>
> Mike
>
> On Fri, Oct 18, 2019 at 11:06 AM Peter Moberg 
> wrote:
>
>> As a follow-up.
>>
>> On the Nifi node I am able to do a GET to Elastic Search using curl. I
>> specify the —cacert option giving it the self-signed root certificate.
>>
>> Of course, this isn’t using the TrustStore but I am able to use the
>> TrustStore if I use other ES processors… just not the
>> ElasticSearchClientServicesImpl.
>>
>> On Oct 18, 2019, 12:48 AM -0500, Peter Moberg ,
>> wrote:
>>
>> Hi Andy,
>>
>> thanks for your suggestions. Here is what I have tried so far (still no
>> luck).
>>
>> Connecting with openssl and viewing the certs it presents
>>
>> *openssl s_client -connect quickstart-es-http.es
>> -cluster -showcerts*
>>
>> If I then look inside the server cert I can find this
>>
>>
>>
>>
>>
>> *Server Cert: Issuer: OU = quickstart, CN = quickstart-http X509v3
>> Subject Alternative Name: DNS:quickstart-es-http.es
>> -cluster.es.local, DNS:quickstart-es-http,
>> DNS:quickstart-es-http.es -cluster.svc,
>> DNS:quickstart-es-http.es -cluster*
>>
>>
>> If I look in to the self-signed root cert I find this:
>>
>>
>> *Root Cert: Subject: OU = quickstart, CN = quickstart-http*
>>
>>
>> I now double check  my trust store to make sure the Root Cert is there.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Trust store content Your keystore contains 1 entry Alias name:
>> ca_elastic Creation date: Oct 16, 2019 Entry type: trustedCertEntry Owner:
>> CN=quickstart-http, OU=quickstart Issuer: CN=quickstart-http, OU=quickstart
>> Serial number: 5aa50b6806d2394fff6f98d2b7d4c287 Valid from: Fri Oct 11
>> 14:35:01 UTC 2019 until: Sat Oct 10 14:36:01 UTC 2020 Certificate
>> fingerprints: MD5: 1E:E3:33:13:EA:AC:B5:61:23:DE:2E:1A:D7:9C:AA:F0 SHA1:
>> 62:EC:5B:EB:32:6A:38:3D:6A:6B:F7:10:5A:DE:E6:F1:F0:5B:07:99 SHA256:
>> B4:B5:06:9C:50:5F:E8:A1:58:7C:C7:2C:37:52:2F:E0:CF:32:18:18:68:E4:C7:37:F8:82:B3:BC:61:EB:5B:CF
>> Signature algorithm name: SHA256withRSA Subject Public Key Algorithm:
>> 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19
>> Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2:
>> ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth
>> clientAuth ] #3: ObjectId: 2.5.29.15 Criticality=true KeyUsage [
>> DigitalSignature Key_CertSign ]*
>>
>> So everything looks Ok. But when I run the
>> ElasticSearchClientServicesImpl with a SSLContext pointing to my trust
>> store I still get the following output in the log.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine
>> problem at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at
>> sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) at
>> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330) at
>> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1633)
>> at
>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) at
>> sun.security.ssl.Handshaker$1.run(Handshaker.java:992) at
>> sun.security.ssl.Handshaker$1.run(Handshaker.java:989) at
>> java.security.AccessController.doPrivileged(Native Method) at
>> sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) at
>> org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:283)
>> at
>> org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:353)
>> ... 9 common frames omitted Caused by:
>> sun.security.validator.ValidatorException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
>> valid certification path to requested target at
>> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397) at
>> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
>> at sun.security.validator.Validator.validate(Validator.java:262) at
>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
>> at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1620)
>> ... 17 common frames omitted*
>>
>> Both the Nifi install and Elastic Search install is 

Re: ElasticSearchClientServiceImpl not working for secured ElasticSearch

[Mike Thomsen]

Peter,

Are you configuring the service as a trust-only configuration? If so,
that's been addressed in the 1.10 which is due for release in the near(ish)
future.

https://issues.apache.org/jira/browse/NIFI-6228

Thanks,

Mike

On Fri, Oct 18, 2019 at 11:06 AM Peter Moberg 
wrote:

> As a follow-up.
>
> On the Nifi node I am able to do a GET to Elastic Search using curl. I
> specify the —cacert option giving it the self-signed root certificate.
>
> Of course, this isn’t using the TrustStore but I am able to use the
> TrustStore if I use other ES processors… just not the
> ElasticSearchClientServicesImpl.
>
> On Oct 18, 2019, 12:48 AM -0500, Peter Moberg ,
> wrote:
>
> Hi Andy,
>
> thanks for your suggestions. Here is what I have tried so far (still no
> luck).
>
> Connecting with openssl and viewing the certs it presents
>
> *openssl s_client -connect quickstart-es-http.es
> -cluster -showcerts*
>
> If I then look inside the server cert I can find this
>
>
>
>
>
> *Server Cert: Issuer: OU = quickstart, CN = quickstart-http X509v3 Subject
> Alternative Name: DNS:quickstart-es-http.es
> -cluster.es.local, DNS:quickstart-es-http,
> DNS:quickstart-es-http.es -cluster.svc,
> DNS:quickstart-es-http.es -cluster*
>
>
> If I look in to the self-signed root cert I find this:
>
>
> *Root Cert: Subject: OU = quickstart, CN = quickstart-http*
>
>
> I now double check  my trust store to make sure the Root Cert is there.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Trust store content Your keystore contains 1 entry Alias name: ca_elastic
> Creation date: Oct 16, 2019 Entry type: trustedCertEntry Owner:
> CN=quickstart-http, OU=quickstart Issuer: CN=quickstart-http, OU=quickstart
> Serial number: 5aa50b6806d2394fff6f98d2b7d4c287 Valid from: Fri Oct 11
> 14:35:01 UTC 2019 until: Sat Oct 10 14:36:01 UTC 2020 Certificate
> fingerprints: MD5: 1E:E3:33:13:EA:AC:B5:61:23:DE:2E:1A:D7:9C:AA:F0 SHA1:
> 62:EC:5B:EB:32:6A:38:3D:6A:6B:F7:10:5A:DE:E6:F1:F0:5B:07:99 SHA256:
> B4:B5:06:9C:50:5F:E8:A1:58:7C:C7:2C:37:52:2F:E0:CF:32:18:18:68:E4:C7:37:F8:82:B3:BC:61:EB:5B:CF
> Signature algorithm name: SHA256withRSA Subject Public Key Algorithm:
> 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19
> Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2:
> ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth
> clientAuth ] #3: ObjectId: 2.5.29.15 Criticality=true KeyUsage [
> DigitalSignature Key_CertSign ]*
>
> So everything looks Ok. But when I run the ElasticSearchClientServicesImpl
> with a SSLContext pointing to my trust store I still get the following
> output in the log.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at
> sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) at
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330) at
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1633)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) at
> sun.security.ssl.Handshaker$1.run(Handshaker.java:992) at
> sun.security.ssl.Handshaker$1.run(Handshaker.java:989) at
> java.security.AccessController.doPrivileged(Native Method) at
> sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) at
> org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:283)
> at
> org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:353)
> ... 9 common frames omitted Caused by:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target at
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397) at
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
> at sun.security.validator.Validator.validate(Validator.java:262) at
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> at
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
> at
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1620)
> ... 17 common frames omitted*
>
> Both the Nifi install and Elastic Search install is running in Kubernetes.
> The address I am using is a service address that is backed by 3 ES
> instances. However, I double checked all three of the ES nodes to make sure
> that they returned back the same SSL cert and they did.
>
> The only thing I haven't been able to 

Implementing a custom provenance reporting task

[Tim Dean]

I would like to implement some custom monitoring logic that captures certain 
information from the provenance repository. It would be similar in some ways to 
the existing SiteToSiteProvenanceReporting task, but it will not be sending 
information to another NiFi node but instead sending things to an in-house 
tracking service that we use.

There is a little information about writing custom reporting tasks in the NiFi 
developer documentation, but it’s pretty limited in what it covers. I want to 
make sure I capture all the events that come in, and I want to be resilient to 
situations when the NiFi node is rebooted, or certain components are stopped 
temporarily, etc.

To get an idea of how to best accomplish this I’ve been looking at the source 
code for SiteToSiteProvenanceReportingTask on GitHub. It appears to push a 
delegate a lot of the details of event capturing to the 
org.apache.nifi.reporting.util.provenance.ProvenanceEventConsumer class. I’ve 
poked around that class to see what it does, and I think I could use it In my 
own custom reporting class to make things easier. However, that class doesn’t 
seem to be documented publicly anywhere, and isn’t mentioned in the developer 
guide. I am concerned that it might be necessary to treat this as a private 
class that may change from release to release.

How would you recommend that I proceed to create my own provenance event 
reporting task? Should I mimic SiteToSiteProvenanceReportingTask and built it 
on top of the ProvenanceEventConsumer class? Should I instead pull out the 
parts of ProvenanceEventConsumer that I need and create my own version of that 
class that I can control? 
Any other approaches I should consider instead of the path I’m heading down now?

Re: ElasticSearchClientServiceImpl not working for secured ElasticSearch

[Peter Moberg]

As a follow-up.

On the Nifi node I am able to do a GET to Elastic Search using curl. I specify 
the —cacert option giving it the self-signed root certificate.

Of course, this isn’t using the TrustStore but I am able to use the TrustStore 
if I use other ES processors… just not the ElasticSearchClientServicesImpl.

On Oct 18, 2019, 12:48 AM -0500, Peter Moberg , wrote:
> Hi Andy,
>
> thanks for your suggestions. Here is what I have tried so far (still no luck).
>
> Connecting with openssl and viewing the certs it presents
>
> openssl s_client -connect quickstart-es-http.es-cluster -showcerts
>
> If I then look inside the server cert I can find this
>
> Server Cert:
> Issuer: OU = quickstart, CN = quickstart-http
>
> X509v3 Subject Alternative Name:
> DNS:quickstart-es-http.es-cluster.es.local, DNS:quickstart-es-http, 
> DNS:quickstart-es-http.es-cluster.svc, DNS:quickstart-es-http.es-cluster
>
>
> If I look in to the self-signed root cert I find this:
>
> Root Cert:
> Subject: OU = quickstart, CN = quickstart-http
>
>
> I now double check  my trust store to make sure the Root Cert is there.
>
> Trust store content
> Your keystore contains 1 entry
>
> Alias name: ca_elastic
> Creation date: Oct 16, 2019
> Entry type: trustedCertEntry
>
> Owner: CN=quickstart-http, OU=quickstart
> Issuer: CN=quickstart-http, OU=quickstart
> Serial number: 5aa50b6806d2394fff6f98d2b7d4c287
> Valid from: Fri Oct 11 14:35:01 UTC 2019 until: Sat Oct 10 14:36:01 UTC 2020
> Certificate fingerprints:
> MD5: 1E:E3:33:13:EA:AC:B5:61:23:DE:2E:1A:D7:9C:AA:F0
> SHA1: 62:EC:5B:EB:32:6A:38:3D:6A:6B:F7:10:5A:DE:E6:F1:F0:5B:07:99
> SHA256: 
> B4:B5:06:9C:50:5F:E8:A1:58:7C:C7:2C:37:52:2F:E0:CF:32:18:18:68:E4:C7:37:F8:82:B3:BC:61:EB:5B:CF
> Signature algorithm name: SHA256withRSA
> Subject Public Key Algorithm: 2048-bit RSA key
> Version: 3
>
> Extensions:
>
> #1: ObjectId: 2.5.29.19 Criticality=true
> BasicConstraints:[
> CA:true
> PathLen:2147483647
> ]
>
> #2: ObjectId: 2.5.29.37 Criticality=false
> ExtendedKeyUsages [
> serverAuth
> clientAuth
> ]
>
> #3: ObjectId: 2.5.29.15 Criticality=true
> KeyUsage [
> DigitalSignature
> Key_CertSign
> ]
>
> So everything looks Ok. But when I run the ElasticSearchClientServicesImpl 
> with a SSLContext pointing to my trust store I still get the following output 
> in the log.
>
> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
> at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1633)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
> at 
> org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:283)
> at 
> org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:353)
> ... 9 common frames omitted
> Caused by: sun.security.validator.ValidatorException: PKIX path building 
> failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to 
> find valid certification path to requested target
> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
> at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
> at sun.security.validator.Validator.validate(Validator.java:262)
> at 
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> at 
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
> at 
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
> at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1620)
> ... 17 common frames omitted
>
> Both the Nifi install and Elastic Search install is running in Kubernetes. 
> The address I am using is a service address that is backed by 3 ES instances. 
> However, I double checked all three of the ES nodes to make sure that they 
> returned back the same SSL cert and they did.
>
> The only thing I haven't been able to figure out is how to check if 
> Kubernetes/ES reacts differently when you do a GET vs POST. Feels strange 
> that it would return different SSL certs but stranger things have happened…
>
>
>
> On Oct 17, 2019, 3:25 PM -0500, Andy LoPresto , wrote:
> > Hi Peter,
> >
> > If you can use openssl’s s_client command (example below) to connect to the 
> > endpoint and verify that the hostname matches the certificate and that the 
> > certificate contains a SubjectAlternativeName entry with that 

Re: Re: MergeRecord can not guarantee the ordering of the input sequence?

[wangl...@geekplus.com.cn]

Seems it is because of the balance strategy that is used. 
The balance will not guarantee the the order.

Thanks,
Lei



wangl...@geekplus.com.cn
 
From: wangl...@geekplus.com.cn
Date: 2019-10-16 10:21
To: dev; users
CC: dev
Subject: Re: Re: MergeRecord can not guarantee the ordering of the input 
sequence?
Hi Koji, 
Actually i have set all connections to FIFO and concurrency tasks to 1 for all 
processors.
Before and after the MergeRecord, I add a LogAttribute to debug.
 
Before MergeRecord，the order in logfile is A,B,C in three flowfile 
After  MergeRecord, the order becomes {A,C,B} in one flowfile
This is nondeterministic.
 
I think I should look up the MergeRecord code and do further debug.
 
Thanks, 
Lei
 
 
 
 
wangl...@geekplus.com.cn
From: Koji Kawamura
Date: 2019-10-16 09:46
To: users
CC: dev
Subject: Re: MergeRecord can not guarantee the ordering of the input sequence?
Hi Lei,
How about setting FIFO prioritizer at all the preceding connections
before the MergeRecord?
Without setting any prioritizer, FlowFile ordering is nondeterministic.
Thanks,
Koji
On Tue, Oct 15, 2019 at 8:56 PM wangl...@geekplus.com.cn
 wrote:
>
>
> If  FlowFile A, B, C enter the MergeRecord sequentially, the output should be 
> one FlowFile {A, B, C}
> However, when testing with  large data volume, sometimes the output order 
> will be not the same as they enter. And this result is nondeterministic
>
> This really confuses me a lot.
> Anybody has any insight on this?
>
> Thanks，
> Lei
>
> 
> wangl...@geekplus.com.cn