Apache NiFi-1.15.1 Older sl4j and log4j jars

[Chahat Madaan]

Hi,

 

As per release notes of NiFi 1.15.1, all the log4j.2.X dependencies has been 
upgraded to 2.16. But while deploying the latest NiFi Version, I can see some 
older JARs like log4j-over-slf4j-1.7.32.jar, jul-to-slf4j-1.7.32.jar, 
slf4j-api-1.7.32.jar. I just want to confirm if they are affected with latest 
log4j vulnerability or they are safe to use with latest NiFi Version.

 

Thanks and Regards

Chahat Madaan

+91 844 874 3588

 

 

 

From: Chahat Madaan 
Date: Friday, 17 December 2021 at 1:12 PM
To: 
Cc: Snehadeep Vikram 
Subject: Apache NiFi-1.15.1 Older sl4j and log4j jars

 

Hi,

 

As per release notes of NiFi 1.15.1, all the log4j.2.X dependencies has been 
upgraded to 2.16. But while deploying the lastest NiFi Version, I can see some 
older JARs like log4j-over-slf4j-1.7.32.jar, jul-to-slf4j-1.7.32.jar, 
slf4j-api-1.7.32.jar. I just want to confirm if they are affected with latest 
log4j vulnerability or they are safe to use with lastest NiFi Version.

 

Thanks and Regards

Chahat Madaan

+91 844 874 3588

 

 

Changing username and password on windows

[Matt Cuba]

Hi there,

How does one change the default username and password for NiFi 1.15.1 for a 
windows installation? NiFi.sh is a Linux script. At this point I cannot migrate 
to a docker install.

Thanks,
Matt

RE: javax.net.ssl.SSLPeerUnverifiedException

[Lior Halperin]

https://issues.apache.org/jira/browse/NIFI-3081
maybe related to this?



Internal Use - Confidential
From: Lior Halperin
Sent: Thursday, 16 December 2021 11:27
To: users@nifi.apache.org; d...@nifi.apache.org
Subject: javax.net.ssl.SSLPeerUnverifiedException

Hi,
We are using nifi 1.15 secured cluster with external zk 3.7.0 defined in the zk 
conf:
ssl.hostnameVerification=false
ssl.quorum.hostnameVerification=false
sslQuorum=false
also in the nifi nodes zookeeper properties we defined
ssl.hostnameVerification=false
ssl.quorum.hostnameVerification=false

on nifi start up nodes we get :
2021-12-15 21:57:43,440 ERROR [nioEventLoopGroup-2-1] 
o.apache.zookeeper.common.ZKTrustManager Failed to verify host address: 
127.0.0.1
javax.net.ssl.SSLPeerUnverifiedException: Certificate for 
<127.0.0.1> doesn't match common name of the certificate subject: APP SERVER KEY




what are definitions we miss that should eliminate the 
SSLPeerUnverifiedException?



Internal Use - Confidential

RE: javax.net.ssl.SSLPeerUnverifiedException

[Lior Halperin]

nifi.zookeeper.connect.string=vm-nifi-secured-01:2281
(currently we did one machine with zk)



Internal Use - Confidential
From: Mark Payne 
Sent: Thursday, 16 December 2021 16:20
To: users
Subject: Re: javax.net.ssl.SSLPeerUnverifiedException

[EXTERNAL MAIL]

Lior,

What do you have set for the “nifi.zookeeper.connect.string” property in 
nifi.properties?

Thanks
-Mark


On Dec 16, 2021, at 4:26 AM, Lior Halperin 
mailto:lior.halpe...@outseer.com>> wrote:

Hi,
We are using nifi 1.15 secured cluster with external zk 3.7.0 defined in the zk 
conf:
ssl.hostnameVerification=false
ssl.quorum.hostnameVerification=false
sslQuorum=false
also in the nifi nodes zookeeper properties we defined
ssl.hostnameVerification=false
ssl.quorum.hostnameVerification=false

on nifi start up nodes we get :
2021-12-15 21:57:43,440 ERROR [nioEventLoopGroup-2-1] 
o.apache.zookeeper.common.ZKTrustManager Failed to verify host address: 
127.0.0.1
javax.net.ssl.SSLPeerUnverifiedException:
 Certificate for <127.0.0.1> doesn't match common name of the certificate 
subject: APP SERVER KEY




what are definitions we miss that should eliminate the 
SSLPeerUnverifiedException?


Internal Use - Confidential

Re: javax.net.ssl.SSLPeerUnverifiedException

[Mark Payne]

Lior,

What do you have set for the “nifi.zookeeper.connect.string” property in 
nifi.properties?

Thanks
-Mark


On Dec 16, 2021, at 4:26 AM, Lior Halperin 
mailto:lior.halpe...@outseer.com>> wrote:

Hi,
We are using nifi 1.15 secured cluster with external zk 3.7.0 defined in the zk 
conf:
ssl.hostnameVerification=false
ssl.quorum.hostnameVerification=false
sslQuorum=false
also in the nifi nodes zookeeper properties we defined
ssl.hostnameVerification=false
ssl.quorum.hostnameVerification=false

on nifi start up nodes we get :
2021-12-15 21:57:43,440 ERROR [nioEventLoopGroup-2-1] 
o.apache.zookeeper.common.ZKTrustManager Failed to verify host address: 
127.0.0.1
javax.net.ssl.SSLPeerUnverifiedException: Certificate for 
<127.0.0.1> doesn't match common name of the certificate subject: APP SERVER KEY




what are definitions we miss that should eliminate the 
SSLPeerUnverifiedException?


Internal Use - Confidential

Re: NiFi flow.xml.gz corruption

[Mark Payne]

Hi Ravi,

Not sure why you would be seeing the flow get corrupted. When you say 
“corrupted” - do you mean truly corrupted? As in, the file cannot be 
read/parsed? Or do you mean that it’s out of sync, meaning that NiFi can read 
it but won’t join the cluster because its flow is different from the cluster’s 
flow?

In either case, though, removing the file and restarting is the easiest option 
traditionally. Within Kubernetes I can see how this would get complicated. In 
the upcoming release (1.16) we have made a lot of improvements around 
clustering that should resolve this. But you’d need to update to the latest to 
get these improvements.

I don’t know enough about kubernetes to make any recommendations about 
lifecycle hooks, etc. You could certainly reach out to the Kubernetes community 
about that.

As far as NiFi registry goes: I don’t think it’s going to help here. NiFi 
Registry makes it convenient to build a dataflow and then store it in the 
registry. You can then check out that flow in another NiFi instance (or 
checkout a second copy in the same NiFi instance) and then see when changes are 
made, update to the newest version of the flow, etc. Think version control for 
individual Process Groups.

Hope this helps!
-Mark


> On Dec 16, 2021, at 3:54 AM, Ravi Nallappan  wrote:
> 
> Hi,
> 
> A general question regarding flow.xml.gz. (Nifi version 1.10.0)
> 
> We have about 6-8 nifi nodes in a cluster (kubernetes environment) and we do 
> see the file get corrupted at times and causing the node to not come up on 
> restarts and eventually kubernetes gives up.
> 
> Based on my search on the issue, shows the easiest recovery is to remove the 
> corrupted flow.xml.gz and let the node come up, join the cluster and sync up 
> with golden copy from other nodes.
> 
> However, this will be a challenge to do in kubernetes environment, any 
> suggestion on this? (possibly can write a script to check and do the action, 
> but how do we add the hook to do just the pod gets restarted)
> 
> Is NiFi Registry a better recommendation in production environment? If yes, 
> will look at this as a longer term solution.
> 
> Thanks in advance.
> 
> regards,
> 
> Ravi Nallappan
> 

javax.net.ssl.SSLPeerUnverifiedException

[Lior Halperin]

Hi,
We are using nifi 1.15 secured cluster with external zk 3.7.0 defined in the zk 
conf:
ssl.hostnameVerification=false
ssl.quorum.hostnameVerification=false
sslQuorum=false
also in the nifi nodes zookeeper properties we defined
ssl.hostnameVerification=false
ssl.quorum.hostnameVerification=false

on nifi start up nodes we get :
2021-12-15 21:57:43,440 ERROR [nioEventLoopGroup-2-1] 
o.apache.zookeeper.common.ZKTrustManager Failed to verify host address: 
127.0.0.1
javax.net.ssl.SSLPeerUnverifiedException: Certificate for 
<127.0.0.1> doesn't match common name of the certificate subject: APP SERVER KEY




what are definitions we miss that should eliminate the 
SSLPeerUnverifiedException?



Internal Use - Confidential

NiFi flow.xml.gz corruption

[Ravi Nallappan]

Hi,

A general question regarding flow.xml.gz. (Nifi version 1.10.0)

We have about 6-8 nifi nodes in a cluster (kubernetes environment) and we
do see the file get corrupted at times and causing the node to not come up
on restarts and eventually kubernetes gives up.

Based on my search on the issue, shows the easiest recovery is to remove
the corrupted flow.xml.gz and let the node come up, join the cluster and
sync up with golden copy from other nodes.

However, this will be a challenge to do in kubernetes environment, any
suggestion on this? (possibly can write a script to check and do the
action, but how do we add the hook to do just the pod gets restarted)

Is NiFi Registry a better recommendation in production environment? If yes,
will look at this as a longer term solution.

Thanks in advance.

regards,

Ravi Nallappan