HDP: Symlinks to jars not getting followed and scanned for JndiLookup.class files

[dins2k2]

Observation from a test run of log4j patch script on HDP:

Looks like if a OS directory has symlinks to jars, its not getting followed and scanned for JndiLookup.class files.

grep: /usr/hdp/current/phoenix-server/lib/hbase-testing-util.jar: No such file or directory

Test run Log:

[root@server]# ./run_log4j_patcher.sh hdp
INFO : Running HDP/HDF patcher script: ./hdp_log4j_jndi_removal.sh '/usr/hdp/current /usr/hdf/current /usr/lib /var/lib' /opt/cloudera/log4shell-backup
INFO : Log file: output_run_log4j_patcher.hjH6lO
.
Removing JNDI from jar files
Running on '/usr/hdp/current'
Backing up files to '/opt/cloudera/log4shell-backup'
grep: /usr/hdp/current/hadoop-client/lib/ojdbc6.jar: No such file or directory
grep: /usr/hdp/current/hbase-client/lib/ojdbc6.jar: No such file or directory
grep: /usr/hdp/current/hbase-master/lib/ojdbc6.jar: No such file or directory
grep: /usr/hdp/current/hbase-regionserver/lib/ojdbc6.jar: No such file or directory
grep: /usr/hdp/current/phoenix-client/lib/hbase-testing-util.jar: No such file or directory
grep: /usr/hdp/current/phoenix-server/lib/hbase-testing-util.jar: No such file or directory
Running on '/usr/hdf/current'
Backing up files to '/opt/cloudera/log4shell-backup'
Running on '/usr/lib'
Backing up files to '/opt/cloudera/log4shell-backup'
Running on '/var/lib'
Backing up files to '/opt/cloudera/log4shell-backup'
Run successful
INFO : Finished
[root@server]#

Symlink: [user@server]$ ll /usr/hdp/current/phoenix-client/lib/hbase-testing-util.jar lrwxrwxrwx 1 root root 52 May 22 2018 /usr/hdp/current/phoenix-client/lib/hbase-testing-util.jar -> /usr/hdp/2.6.4.0-91/hbase/lib/hbase-testing-util.jar

Any fix for this? Or am I missing something?

[starkjs]

You don't want it to touch any symlink, they should all be ignored. All files should be scanned. Then any symlink to these files will be ok,as there is usually multiple symlinks to one file

[belugabehr]

Seems related to #26

[jtran-cloudera]

Currently, the scan does follow symlinks (though it arguably should not). Do the symlinks point to valid files?

[starkjs]

It SHOULD NOT use synlinks, as the backup will not be the true file and makes rollback hard. There is also issues with permission of the backup file, so on restore it can break access based on the systems security level with its umask setting

[dins2k2]

Currently, the scan does follow symlinks (though it arguably should not). Do the symlinks point to valid files?

I just had a quick check, seems the symlinks pointing to the non-existing jars.

[dins2k2]

I think this issue can be closed. Thanks for all your help!