Re: [discuss] nifi 1.14.0

[Joe Witt]

So. Dang. Cool.  I just built from latest main and poof - I'm on https
with username/password.

Will start whipping up the process for an RC.  Probably will be a
little slow going with dayjob factors but will get on it.

Thanks

On Fri, Jun 11, 2021 at 12:14 PM David Handermann
 wrote:
>
> Thanks to Mark Payne, NIFI-8516 is now merged, so that covers current open
> issues around securing the default configuration.
>
> Regards,
> David Handermann
>
> On Fri, Jun 11, 2021 at 11:55 AM David Handermann <
> exceptionfact...@apache.org> wrote:
>
> > Joe,
> >
> > Thanks for following up.  The PR for NIFI-8516 has gone through several
> > rounds of feedback, I believe it is about ready to go, pending confirmation
> > that the ability to set custom credentials addresses the ease of use
> > concern.
> >
> > Regards,
> > David Handermann
> >
> > On Fri, Jun 11, 2021 at 11:41 AM Joe Witt  wrote:
> >
> >> David,
> >>
> >> Ok thanks - do you have a sense of when what you see as good 1.14
> >> specific work will be merged?  Do you have the reviewers/engagement
> >> you need?
> >>
> >> This 1.14 is already pretty packed but definitely agree we need to
> >> make real progress on secure by default and this release is a great
> >> time to take the first big step.
> >>
> >> Thanks
> >>
> >> On Mon, May 31, 2021 at 5:52 AM David Handermann
> >>  wrote:
> >> >
> >> > Thanks for kicking off the discussion Joe!
> >> >
> >> > Of the many items that could be included in the next release, securing
> >> the
> >> > default configuration as described in NIFI-8220
> >> >  would be great to
> >> have
> >> > completed.  Most of the elements are in place, and the current Pull
> >> Request
> >> > for NIFI-8516  is under
> >> review.
> >> > If there are any other achievable items that should be included as part
> >> of
> >> > a secure default installation for NiFi, it would be helpful to add
> >> > sub-tasks to NIFI-8220.  The current scope is limited to a standalone
> >> > installation, so issues regarding clustered deployments can be handled
> >> > separately.  If others are interested in evaluating the proposed new
> >> > default configuration that requires HTTPS and leverages a generated
> >> > username and password, feel free to provide feedback on NIFI-8516.
> >> >
> >> > Regards,
> >> > David Handermann
> >> >
> >> > On Thu, May 27, 2021 at 6:51 PM Otto Fowler 
> >> wrote:
> >> >
> >> > > I think NIFI-8625 and NIFI-8461 need to be understood and addressed.
> >> > >
> >> > >
> >> > > > On May 27, 2021, at 13:29, Joe Witt  wrote:
> >> > > >
> >> > > > Team,
> >> > > >
> >> > > > There has been a tremendous amount of work already on the 1.14 line
> >> as
> >> > > shown:
> >> > > >
> >> > > > https://issues.apache.org/jira/projects/NIFI/versions/12349644
> >> > > >
> >> > > > These include merging the nifi registry and minifi java into the
> >> nifi
> >> > > > line itself.  So when we release these things stay in sync and
> >> > > > maintained.  The release will now produce things like Apache NiFi,
> >> the
> >> > > > Apache NiFi toolkit, Apache NiFi Registry, and Apache NiFi MiNiFi
> >> Java
> >> > > > and the Apache NiFi stateless runtime as well.  There have been many
> >> > > > improvements to core nifi and stateless nifi now meaning we have the
> >> > > > traditional execution form factor and this new stateless mode.  We
> >> can
> >> > > > now hot load nars from HDFS storage locations which could mean HDFS,
> >> > > > blob storage in the cloud, etc..  There is a lot more.
> >> > > >
> >> > > > Anyway, I wanted to start circling the wagons for a 1.14 release.
> >> I'm
> >> > > > happy to take on RM duties especially since there will be new
> >> elements
> >> > > > to the release process.
> >> > > >
> >> > > > Thanks
> >> > >
> >> > >
> >>
> >

Re: [discuss] nifi 1.14.0

[David Handermann]

Thanks to Mark Payne, NIFI-8516 is now merged, so that covers current open
issues around securing the default configuration.

Regards,
David Handermann

On Fri, Jun 11, 2021 at 11:55 AM David Handermann <
exceptionfact...@apache.org> wrote:

> Joe,
>
> Thanks for following up.  The PR for NIFI-8516 has gone through several
> rounds of feedback, I believe it is about ready to go, pending confirmation
> that the ability to set custom credentials addresses the ease of use
> concern.
>
> Regards,
> David Handermann
>
> On Fri, Jun 11, 2021 at 11:41 AM Joe Witt  wrote:
>
>> David,
>>
>> Ok thanks - do you have a sense of when what you see as good 1.14
>> specific work will be merged?  Do you have the reviewers/engagement
>> you need?
>>
>> This 1.14 is already pretty packed but definitely agree we need to
>> make real progress on secure by default and this release is a great
>> time to take the first big step.
>>
>> Thanks
>>
>> On Mon, May 31, 2021 at 5:52 AM David Handermann
>>  wrote:
>> >
>> > Thanks for kicking off the discussion Joe!
>> >
>> > Of the many items that could be included in the next release, securing
>> the
>> > default configuration as described in NIFI-8220
>> >  would be great to
>> have
>> > completed.  Most of the elements are in place, and the current Pull
>> Request
>> > for NIFI-8516  is under
>> review.
>> > If there are any other achievable items that should be included as part
>> of
>> > a secure default installation for NiFi, it would be helpful to add
>> > sub-tasks to NIFI-8220.  The current scope is limited to a standalone
>> > installation, so issues regarding clustered deployments can be handled
>> > separately.  If others are interested in evaluating the proposed new
>> > default configuration that requires HTTPS and leverages a generated
>> > username and password, feel free to provide feedback on NIFI-8516.
>> >
>> > Regards,
>> > David Handermann
>> >
>> > On Thu, May 27, 2021 at 6:51 PM Otto Fowler 
>> wrote:
>> >
>> > > I think NIFI-8625 and NIFI-8461 need to be understood and addressed.
>> > >
>> > >
>> > > > On May 27, 2021, at 13:29, Joe Witt  wrote:
>> > > >
>> > > > Team,
>> > > >
>> > > > There has been a tremendous amount of work already on the 1.14 line
>> as
>> > > shown:
>> > > >
>> > > > https://issues.apache.org/jira/projects/NIFI/versions/12349644
>> > > >
>> > > > These include merging the nifi registry and minifi java into the
>> nifi
>> > > > line itself.  So when we release these things stay in sync and
>> > > > maintained.  The release will now produce things like Apache NiFi,
>> the
>> > > > Apache NiFi toolkit, Apache NiFi Registry, and Apache NiFi MiNiFi
>> Java
>> > > > and the Apache NiFi stateless runtime as well.  There have been many
>> > > > improvements to core nifi and stateless nifi now meaning we have the
>> > > > traditional execution form factor and this new stateless mode.  We
>> can
>> > > > now hot load nars from HDFS storage locations which could mean HDFS,
>> > > > blob storage in the cloud, etc..  There is a lot more.
>> > > >
>> > > > Anyway, I wanted to start circling the wagons for a 1.14 release.
>> I'm
>> > > > happy to take on RM duties especially since there will be new
>> elements
>> > > > to the release process.
>> > > >
>> > > > Thanks
>> > >
>> > >
>>
>

Re: [discuss] nifi 1.14.0

[David Handermann]

Joe,

Thanks for following up.  The PR for NIFI-8516 has gone through several
rounds of feedback, I believe it is about ready to go, pending confirmation
that the ability to set custom credentials addresses the ease of use
concern.

Regards,
David Handermann

On Fri, Jun 11, 2021 at 11:41 AM Joe Witt  wrote:

> David,
>
> Ok thanks - do you have a sense of when what you see as good 1.14
> specific work will be merged?  Do you have the reviewers/engagement
> you need?
>
> This 1.14 is already pretty packed but definitely agree we need to
> make real progress on secure by default and this release is a great
> time to take the first big step.
>
> Thanks
>
> On Mon, May 31, 2021 at 5:52 AM David Handermann
>  wrote:
> >
> > Thanks for kicking off the discussion Joe!
> >
> > Of the many items that could be included in the next release, securing
> the
> > default configuration as described in NIFI-8220
> >  would be great to have
> > completed.  Most of the elements are in place, and the current Pull
> Request
> > for NIFI-8516  is under
> review.
> > If there are any other achievable items that should be included as part
> of
> > a secure default installation for NiFi, it would be helpful to add
> > sub-tasks to NIFI-8220.  The current scope is limited to a standalone
> > installation, so issues regarding clustered deployments can be handled
> > separately.  If others are interested in evaluating the proposed new
> > default configuration that requires HTTPS and leverages a generated
> > username and password, feel free to provide feedback on NIFI-8516.
> >
> > Regards,
> > David Handermann
> >
> > On Thu, May 27, 2021 at 6:51 PM Otto Fowler 
> wrote:
> >
> > > I think NIFI-8625 and NIFI-8461 need to be understood and addressed.
> > >
> > >
> > > > On May 27, 2021, at 13:29, Joe Witt  wrote:
> > > >
> > > > Team,
> > > >
> > > > There has been a tremendous amount of work already on the 1.14 line
> as
> > > shown:
> > > >
> > > > https://issues.apache.org/jira/projects/NIFI/versions/12349644
> > > >
> > > > These include merging the nifi registry and minifi java into the nifi
> > > > line itself.  So when we release these things stay in sync and
> > > > maintained.  The release will now produce things like Apache NiFi,
> the
> > > > Apache NiFi toolkit, Apache NiFi Registry, and Apache NiFi MiNiFi
> Java
> > > > and the Apache NiFi stateless runtime as well.  There have been many
> > > > improvements to core nifi and stateless nifi now meaning we have the
> > > > traditional execution form factor and this new stateless mode.  We
> can
> > > > now hot load nars from HDFS storage locations which could mean HDFS,
> > > > blob storage in the cloud, etc..  There is a lot more.
> > > >
> > > > Anyway, I wanted to start circling the wagons for a 1.14 release.
> I'm
> > > > happy to take on RM duties especially since there will be new
> elements
> > > > to the release process.
> > > >
> > > > Thanks
> > >
> > >
>

Re: [discuss] nifi 1.14.0

[Joe Witt]

David,

Ok thanks - do you have a sense of when what you see as good 1.14
specific work will be merged?  Do you have the reviewers/engagement
you need?

This 1.14 is already pretty packed but definitely agree we need to
make real progress on secure by default and this release is a great
time to take the first big step.

Thanks

On Mon, May 31, 2021 at 5:52 AM David Handermann
 wrote:
>
> Thanks for kicking off the discussion Joe!
>
> Of the many items that could be included in the next release, securing the
> default configuration as described in NIFI-8220
>  would be great to have
> completed.  Most of the elements are in place, and the current Pull Request
> for NIFI-8516  is under review.
> If there are any other achievable items that should be included as part of
> a secure default installation for NiFi, it would be helpful to add
> sub-tasks to NIFI-8220.  The current scope is limited to a standalone
> installation, so issues regarding clustered deployments can be handled
> separately.  If others are interested in evaluating the proposed new
> default configuration that requires HTTPS and leverages a generated
> username and password, feel free to provide feedback on NIFI-8516.
>
> Regards,
> David Handermann
>
> On Thu, May 27, 2021 at 6:51 PM Otto Fowler  wrote:
>
> > I think NIFI-8625 and NIFI-8461 need to be understood and addressed.
> >
> >
> > > On May 27, 2021, at 13:29, Joe Witt  wrote:
> > >
> > > Team,
> > >
> > > There has been a tremendous amount of work already on the 1.14 line as
> > shown:
> > >
> > > https://issues.apache.org/jira/projects/NIFI/versions/12349644
> > >
> > > These include merging the nifi registry and minifi java into the nifi
> > > line itself.  So when we release these things stay in sync and
> > > maintained.  The release will now produce things like Apache NiFi, the
> > > Apache NiFi toolkit, Apache NiFi Registry, and Apache NiFi MiNiFi Java
> > > and the Apache NiFi stateless runtime as well.  There have been many
> > > improvements to core nifi and stateless nifi now meaning we have the
> > > traditional execution form factor and this new stateless mode.  We can
> > > now hot load nars from HDFS storage locations which could mean HDFS,
> > > blob storage in the cloud, etc..  There is a lot more.
> > >
> > > Anyway, I wanted to start circling the wagons for a 1.14 release.  I'm
> > > happy to take on RM duties especially since there will be new elements
> > > to the release process.
> > >
> > > Thanks
> >
> >

Re: SSLPeerUnverifiedException following upgrade from 1.6.0 to 1.13.2

[James Srinivasan]

This is my usual go-to reference for getting SANs working with openssl CSRs:

https://geekflare.com/san-ssl-certificate/

Newer openssl versions apparently allow it on the command line:

https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-the-command-line

On Fri, 11 Jun 2021 at 13:00, Phil H  wrote:
>
> Well, it took a lot of mis steps recreating and signing the certs (used the
> wrong CA) and working through all the other issues with SANs, BUT I GOT IT
> WORKING!
>
> Thanks David, and thanks to everyone else that helps out in this group!
> Nifi is so complicated I can’t imagine trying to do this stuff alone!
>
> On Fri, 11 Jun 2021 at 15:09, David Handermann 
> wrote:
>
> > Hi Phil,
> >
> > Thanks for providing the stack trace.  Recent versions of NiFi include
> > updates to the OkHttp library, which modified the hostname verification
> > process.  OkHttp starting with version 3.10.0 made changes to TLS hostname
> > verification, requiring that a certificate contain DNS Subject Alternative
> > Names matching the connection hostname.  Based on the error message, it
> > appears that the certificates configured do not have any Subject
> > Alternative Names, resulting in the SSLPeerUnverifiedException.  Generating
> > or obtaining new certificates that include the required DNS Subject
> > Alternative Names should resolve the problem.
> >
> > Here's the release notes for OkHttp 3.10.0, referencing RFC 2818, which
> > deprecated falling back to certificate common names for hostname
> > verification:
> >
> > https://square.github.io/okhttp/changelog_3x/#version-3100
> >
> > Regards,
> > David Handermann
> >
> > On Thu, Jun 10, 2021 at 11:16 PM Phil H  wrote:
> >
> > > Hi there,
> > >
> > > I upgraded an older dev setup today from 1.6.0 to 1.13.2.  After a
> > > couple of config tweaks, it’s “working”, but if I try and access the
> > > interface at https://nifi2.domain.blah/ I get a message on screen
> > > stating that nifi1.domain.blah is not verified.  The logs contain this
> > > same message, along with the stack trace.  (This also happens if I
> > > access nifi1 – it complains nifi2 is not verified).
> > >
> > > My keystore and truststore on both servers both contain the certs for
> > > both servers, and the truststore additionally contains the CA that
> > > signed both servers’ certificates.
> > >
> > > What am I missing?
> > >
> > > Thanks,
> > > Phil
> > >
> > >
> > >
> > >
> > >
> > > 2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
> > > o.a.n.c.c.h.r.ThreadPoolRequestReplicator Failed to replicate request
> > > GET /nifi-api/flow/current-user to nifi1.domain.blah:443 due to
> > > javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.domain.blah
> > > not verified:
> > >
> > > certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=
> > >
> > > DN: CN=nifi1.domain.blah, OU=domain, O=blah
> > >
> > > subjectAltNames: []
> > >
> > > 2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
> > > o.a.n.c.c.h.r.ThreadPoolRequestReplicator
> > >
> > > javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.
> > > nifi1.domain.blah not verified:
> > >
> > > certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=
> > >
> > > DN: CN=nifi1.domain.blah OU=domain, O=blah
> > >
> > > subjectAltNames: []
> > >
> > > at
> > >
> > >
> > okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:389)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337)
> > >
> > > at
> > > okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:209)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
> > >
> > > at
> > > okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
> > >
> > > at
> > > okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> > >
> > > at
> > > okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> > >
> > > at
> > >
> > okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
> > >
> > > at
> > >
> > >
> > okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> > >
> > > at
> > >
> > >
> > 

[ANNOUNCE] Apache NiFi MiNiFi C++ 0.10.0 release

[Ferenc Gerlits]

Hello,

The Apache NiFi team would like to announce the release of Apache NiFi
MiNiFi C++ 0.10.0.

New features since the last release:
- new processors:
   * ListS3
   * PutAzureBlobStorage
   * ConsumeKafka
   * PerformanceDataMonitor
   * ConsumeJournald
- add resource consumption data to heartbeats
- build with Visual Studio 2019 on Windows.

A few of the improvements and fixes:
- revive SQL processors
- fix expression language support in PublishKafka
- implement FollowRedirects and SendBody properties in InvokeHTTP
- add Initial Starting Position property to TailFile
- support credential refresh in AWSCredentialsService
- change default C2 protocol to REST
- plus bugfixes, compiler warning fixes etc.

MiNiFi - a subproject of Apache NiFi - is a complementary data collection
approach that supplements the core tenets of NiFi in dataflow management,
focusing on the collection of data at the source of its creation.

Specific goals for the initial thrust of the MiNiFi effort comprise:
 - Small size and low resource consumption
 - Central management of agents
 - Generation of data provenance (full chain of custody of information)
 - Integration with NiFi for follow-on dataflow management.

More details on Apache NiFi - MiNiFi C++ can be found here:
https://nifi.apache.org/minifi

The release artifacts can be downloaded from here:
https://nifi.apache.org/minifi/download.html

Issues closed/resolved for this list can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321520=12349956

Release note highlights can be found here:
https://cwiki.apache.org/confluence/display/MINIFI/Release+Notes#ReleaseNotes-Versioncpp-0.10.0

Thank you,
The Apache NiFi team

Re: SSLPeerUnverifiedException following upgrade from 1.6.0 to 1.13.2

[Phil H]

Well, it took a lot of mis steps recreating and signing the certs (used the
wrong CA) and working through all the other issues with SANs, BUT I GOT IT
WORKING!

Thanks David, and thanks to everyone else that helps out in this group!
Nifi is so complicated I can’t imagine trying to do this stuff alone!

On Fri, 11 Jun 2021 at 15:09, David Handermann 
wrote:

> Hi Phil,
>
> Thanks for providing the stack trace.  Recent versions of NiFi include
> updates to the OkHttp library, which modified the hostname verification
> process.  OkHttp starting with version 3.10.0 made changes to TLS hostname
> verification, requiring that a certificate contain DNS Subject Alternative
> Names matching the connection hostname.  Based on the error message, it
> appears that the certificates configured do not have any Subject
> Alternative Names, resulting in the SSLPeerUnverifiedException.  Generating
> or obtaining new certificates that include the required DNS Subject
> Alternative Names should resolve the problem.
>
> Here's the release notes for OkHttp 3.10.0, referencing RFC 2818, which
> deprecated falling back to certificate common names for hostname
> verification:
>
> https://square.github.io/okhttp/changelog_3x/#version-3100
>
> Regards,
> David Handermann
>
> On Thu, Jun 10, 2021 at 11:16 PM Phil H  wrote:
>
> > Hi there,
> >
> > I upgraded an older dev setup today from 1.6.0 to 1.13.2.  After a
> > couple of config tweaks, it’s “working”, but if I try and access the
> > interface at https://nifi2.domain.blah/ I get a message on screen
> > stating that nifi1.domain.blah is not verified.  The logs contain this
> > same message, along with the stack trace.  (This also happens if I
> > access nifi1 – it complains nifi2 is not verified).
> >
> > My keystore and truststore on both servers both contain the certs for
> > both servers, and the truststore additionally contains the CA that
> > signed both servers’ certificates.
> >
> > What am I missing?
> >
> > Thanks,
> > Phil
> >
> >
> >
> >
> >
> > 2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
> > o.a.n.c.c.h.r.ThreadPoolRequestReplicator Failed to replicate request
> > GET /nifi-api/flow/current-user to nifi1.domain.blah:443 due to
> > javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.domain.blah
> > not verified:
> >
> > certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=
> >
> > DN: CN=nifi1.domain.blah, OU=domain, O=blah
> >
> > subjectAltNames: []
> >
> > 2021-06-11 23:51:20,970 WARN [Replicate Request Thread-1]
> > o.a.n.c.c.h.r.ThreadPoolRequestReplicator
> >
> > javax.net.ssl.SSLPeerUnverifiedException: Hostname nifi1.
> > nifi1.domain.blah not verified:
> >
> > certificate: sha256/Wv+eIBMlpsSS95xKF+Fry9C/jQhFbNS35yfJGK92/5U=
> >
> > DN: CN=nifi1.domain.blah OU=domain, O=blah
> >
> > subjectAltNames: []
> >
> > at
> >
> >
> okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:389)
> >
> > at
> >
> >
> okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337)
> >
> > at
> > okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:209)
> >
> > at
> >
> >
> okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
> >
> > at
> >
> >
> okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
> >
> > at
> > okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
> >
> > at
> > okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
> >
> > at
> >
> >
> okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
> >
> > at
> >
> >
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> >
> > at
> > okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
> >
> > at
> >
> >
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> >
> > at
> >
> okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
> >
> > at
> >
> >
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> >
> > at
> >
> >
> okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
> >
> > at
> >
> >
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> >
> > at
> >
> >
> okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
> >
> > at
> > okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
> >
> > at
> >
> >
> org.apache.nifi.cluster.coordination.http.replication.okhttp.OkHttpReplicationClient.replicate(OkHttpReplicationClient.java:132)
> >
> > at
> >
> >
> 

Re: Bug: Load balancer port binds to localhost in cluster, makes load balancer not accessible

[Jens M. Kofoed]

Hi joe

I had to use either the IP address or 0.0.0.0 to get it to work. Using the host 
name or fqdn didn’t worked. 
Kind regards 
Jens

> Den 11. jun. 2021 kl. 12.28 skrev Joe Gresock :
> 
> Great catch, Jens.  I see the mismatch in the properties vs. the code.  I
> just submitted a PR to address this:
> https://github.com/apache/nifi/pull/5146
> 
> On Fri, Jun 11, 2021 at 12:56 AM Jens M. Kofoed 
> wrote:
> 
>> Dear devoloper
>> 
>> Please take a look at this jira:
>> https://lists.apache.org/list.html?dev@nifi.apache.org
>> NIFI 1.13.2, Java 8, Ubuntu 20.04
>> The load balancer bind to the localhost instead of 0.0.0.0
>> The cluster port bind to 0.0.0.0
>> 
>> Kind regards
>> Jens M. Kofoed
>> 

Re: Bug: Load balancer port binds to localhost in cluster, makes load balancer not accessible

[Joe Gresock]

Great catch, Jens.  I see the mismatch in the properties vs. the code.  I
just submitted a PR to address this:
https://github.com/apache/nifi/pull/5146

On Fri, Jun 11, 2021 at 12:56 AM Jens M. Kofoed 
wrote:

> Dear devoloper
>
> Please take a look at this jira:
> https://lists.apache.org/list.html?dev@nifi.apache.org
> NIFI 1.13.2, Java 8, Ubuntu 20.04
> The load balancer bind to the localhost instead of 0.0.0.0
> The cluster port bind to 0.0.0.0
>
> Kind regards
> Jens M. Kofoed
>

[RESULT][VOTE] Release Apache NiFi MiNiFi C++ 0.10.0

[Ferenc Gerlits]

Apache NiFi Community,

I am pleased to announce that the 0.10.0 release of Apache NiFi MiNiFi C++
passes with
  4 +1 (binding) votes
  5 +1 (non-binding) votes
  0 -1 votes
  0 0 votes
  0 -1 votes

Thanks to all who helped make this release possible.

Here is the PMC vote thread:
https://lists.apache.org/thread.html/r36b8df9d320736ec2819b96482cd14dcafe4954014a6ae8783d74fa1%40%3Cdev.nifi.apache.org%3E