Member since
12-23-2021
3
Posts
0
Kudos Received
0
Solutions
02-02-2022
06:35 PM
That's an odd thing to do 🙂 If you need to use another port for some reason, it would be better to change the ports on all hosts consistently, using the "TCP Port" or the "TLS/SSL Port" properties in Cloudera Manager, whether are you connecting without TLS or with it, respectively. It is possible to configure ports on a host-by-host basis, but it makes it harder to maintain and client configuration becomes a little more cumbersome. To change the port for a particular host, go to Kafka > Instances > Click on the broker your want the change the port for > Configuration > Continue Editing Role Instance. Then enter the following in the "Kafka Broker Advanced Configuration Snippet (Safety Valve) for kafka.properties" property: port=9096 listeners=PLAINTEXT://:9096 The PLAINTEXT value will depend on your cluster config: PLAINTEXT: No Kerberos, No TLS SSL: No Kerberos, Using TLS SASL_PLAINTEXT: Using Kerberos, No TLS SASL_SSL: Using Kerberos, Using TLS After that restart the Broker instance that was reconfigured.
... View more
01-02-2022
08:15 PM
1 Kudo
@noamsh_88, to recap:
You started out the thread saying that you are "using Cloudera V5.1.1 with log4j v1.2.17" and asked how you could upgrade to the latest version of log4j on CDH V5.1.1.
@GangWar replied that CDH 5.x is not and would not be tested with a later version of log4j, as CDH 5.x has reached End of Support (open that link and then expand the section labeled "Cloudera Enterprise products" underneath Current End of Support (EoS) Dates) and so if you tried it, you would be on your own.
He also wrote that CDH-5 was not impacted by the log4j vulnerability described in log4j2 CVE-2021-44228
You replied on 2 Jan that you ran the "patch for log4j provided at https://github.com/cloudera/cloudera-scripts-for-log4j" and asked:
how can we verify our env is out from log4j risk?
is there some java classes we should verify inside?
The very first sentence of the README.md file that renders in the browser automatically when one visits the URL you shared earlier for the cloudera-scripts-for-log4j reads:
This repo contains scripts and helper tools to mitigate the critical log4j vulnerability CVE-2021-44228 for Cloudera products affecting all versions of log4j between 2.0 and 2.14.1.
Emphasis added.
As @GangWar indicated, your environment, based on CDH 5.x, should not have had a version of log4j between 2.0 and 2.14.1 installed, and therefore should not have been vulnerable to the the log4j vulnerability described in log4j2 CVE-2021-44228. This is because, as you yourself pointed out in your original post on 23 Dec, you only had log4j v1.2.17 installed in your environment. log4j v1.2.17 is not a version of log4j between 2.0 and 2.14.1.
This also explains why, after you ran the script intended for systems using log4j versions between 2.0 and 2.14.1 on a system using log4j v1.2.17, the log4j V1 jars were not removed.
But since you ran the script for log4j provided at https://github.com/cloudera/cloudera-scripts-for-log4j anyway and presumably still have it handy, you could check manually for log4j .jar files in your environment in a similar manner that the script does and verify for yourself that none of those files still have the JndiLookup.class still present and thereby verify your environment is not at risk to the log4j vulnerability described in log4j2 CVE-2021-44228 (this information is also in the same README.md file on GitHub where the script you ran is being distributed from).
... View more