@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

@wert_1311 NO, the downtime is recommended.  https://docs.cloudera.com/cdp-private-cloud-upgrade/latest/upgrade-cdh/topics/ug_cdh_upgrade_hdfs_finalize.html ... View more

@Sam2020 Logically this is a maintenance upgrade so no much trouble and extra steps needed.  Your steps looks good till "c" i.e once you upgrade Cloudera Manager server to 7.4.4 there is a very simple steps you need, means just activate the Parcels or 7.1.7 that’s it. In layman’s term these steps will look like this.  I am assuming you have the parcels for 7.1.7 available (credentials and repo details). Then follow below steps. 1.) Please stop the cluster services 2.) Navigate to CM -> hosts -> parcels -> Parcel Repository & Network Settings and include the 7.1.7 parcel "Remote Parcel Repository URLs" 3.) Take the back up of the required service databases following the steps below https://docs.cloudera.com/cdp-private-cloud/latest/upgrade-cdp/topics/ug_cdh_upgrade_backup.html 4.) Download, distribute and activate patch parcel 5.) Start the services. You are all set. ... View more

@GangWar    Hello, This problem has been solved because the atlas service has been deleted, but there are dependencies in other service configurations that have not been cleared.   This can also be seen from the log: ERROR Staleness-Detector-1: com.cloudera.cmf.service.config.components.ProcessStalenessDetector: Failed to check staleness for service client configs : DbService{id=75,name=atlas}   After adding the deleted atlas service back, I succeeded in generating the missing Kerberos credentials again. In short, thank you very much for your reply and wish you a happy life! ... View more