About ask_bill_brooks

ask_bill_brooks · ‎12-01-2022

@Girish007 Sorry, no. I can't suggest any other fix that you can implement in your production environment to mitigate the Log4shell vulnerability. And I would go further and say that I seriously doubt that anyone in a responsible position is going to tell you that you don't "really need to upgrade [y]our current nifi version 1.16.2 to a newer version" in spite of the fact that this specific situation is a great example of how a supposed "important" vulnerability brought to light by certain security scan applications really isn't actually relevant due to the specific way the library is used in a delivered system (which was the point I was trying to make earlier in this thread). I have no doubt at all as to the accuracy of the assessment in the aforementioned Jira, and I also would strongly recommend that you plan to upgrade your current nifi version. My current understanding is that NiFi 1.19.0 included the library upgrade, and the forthcoming CFM 2.1.5.0 version will also include Apache Commons Text 1.10.0.

ask_bill_brooks · ‎11-24-2022

Hi @Arsh43 , You didn't include the Sqoop command you were running or which "form factor" of Cloudera Data Platform (CDP) you were using when you encountered this error message, but you most likely are seeing it because Sqoop needs a Java Development Kit (or JDK), and the OS you are running it from does not have one installed or it isn't accessible. The Sqoop command you were running matters because Sqoop builds Java code for imports and exports. If you had a full JDK installed, at the command line the following commands should produce output BBROOKS-SRVR14150:~ bbrooks$ type javac javac is /usr/bin/javac BBROOKS-SRVR14150:~ bbrooks$ javac -version …that will indicate what version of the JDK's compiler is installed.

ask_bill_brooks · ‎11-21-2022

@dag While you are waiting, can you describe in a bit more detail what you mean by "support NiFi in a commercial environment"? As part of a CDP Subscription, Cloudera supports it's own products, which while they might be based on Apache's releases, are not freely interchangeable with them. One reason for that is there'a always certain differences between the versions released by Cloudera in products such as Cloudera DataFlow (CDF) or Cloudera DataFlow for the Public Cloud (CDF-PC) and the release of "upstream" component projects such as Apache NiFi. This is analogous to how there are differences between what mainline kernel is "current" in the open source Linux world and what RedHat, for example, releases as part of Red Hat Enterprise Linux. In general, Cloudera doesn't provide support for the distributions of NiFi directly downloaded from Apache.

ask_bill_brooks · ‎11-21-2022

@Girish007 The reason I was asking is because what kind of "security scan" you performed matters a great deal. Certain security scan applications are pretty basic and only look at a list of vulnerabilities and the libraries exposed to them and then compare that to a list of libraries using specific version numbers found on/retrieved from the deployed system in question. Many times, this will lead to "false positives" because the system is not actually vulnerable due to the specific way the library is used. Other times, the system vendor will have addressed the vulnerability by changing the code included in the library, without changing the name of major release number denoted in the filename. In the specific case you're interested in, Apache Commons Text is a very popular library, so there are just going to be widespread references to vulnerable versions across anything that uses Apache code. For Apache NiFi, authoritative sources tell me that on initial investigation, NiFi had no direct uses of the vulnerable class, but had many transitive references to the library and that this was patched last month in the open source repository, so updates will be making their way to new versions. You can view the upstream Jira issue here: NIFI-10648

ask_bill_brooks · ‎11-16-2022

@YogeshKumar I'm curious as to exactly how you have determined that, because you have identified that there are previously identified vulnerabilities of critical, high and moderate severity in Log4j1 and Log4j2, that CDH 6.3.4 is exposed to those same vulnerabilities?

ask_bill_brooks · ‎11-15-2022

@hanumanth, Exactly how are you determining that the file path you've identified is exposed to the CVE-2022-42889 vulnerability?

ask_bill_brooks · ‎11-14-2022

@hanumanth I'm just curious as to exactly how you or @Girish007 have determined that a specific release of NiFi is vulnerable to the aforementioned CVE?

ask_bill_brooks · ‎11-12-2022

@yacine_, Authoritative sources tell me that the TEZ UI has not been a supported interface on/in CDP since the first release, so I don't think your efforts to use it will be fruitful. You can view a listing of unsupported interfaces for Hive on CDP Private Cloud Base release 7.1.7 here: Hive unsupported interfaces and features As of this writing, Data Analytics Studio is the only way to get the functionality you're looking for, as the status of TEZ UI hasn't changed for the 7.1.8 release.

ask_bill_brooks · ‎11-07-2022

@yacine_, You didn't say what you are looking to do with the Tez UI, but there is documentation available on the equivalent functionality available in Data Analytics Studio (DAS), which is currently available on CDP, here: Difference between Tez UI and DAS

ask_bill_brooks · ‎10-17-2022

@yagoaparecidoti I think it's unlikely. By consulting this page: Configuring and Using Zeppelin Interpreters You can see a list of Zeppelin interpreters currently supported on Cloudera Data Platform. The python interpreter you are attempting to install is not one of them. This may be resolved in a subsequent release of CDP, but the version you are running now isn't able to fetch dependencies for that interpreter because they aren't available.