Member since
04-22-2014
1218
Posts
341
Kudos Received
157
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
18917 | 03-03-2020 08:12 AM | |
10148 | 02-28-2020 10:43 AM | |
3049 | 12-16-2019 12:59 PM | |
2327 | 11-12-2019 03:28 PM | |
4121 | 11-01-2019 09:01 AM |
05-25-2020
10:11 PM
Hi @bgooley ! thanks for replying back. sorry for the delay since this COVID-19 situation i can't get to the cluster for troubleshooting steps until now. To follow up the test using the keystore and truststore of each cluster CM, i found that JKS files in both clusters CM are contains 2 entries : PrivateKeyEntry and trustedCertEntry with Certificate fingerprint (SHA1) completely identical, only differs in alias name Target BDR JKS content: Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
servercert, Dec 20, 2019, PrivateKeyEntry,
Certificate fingerprint (SHA1): D8:41:3A:3E:D8:9B:81:0E:D8:49:F7:3E:F1:93:52:C5:FC:BB:E7:CE
cmdrc.company.co.id, Dec 20, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): D8:41:3A:3E:D8:9B:81:0E:D8:49:F7:3E:F1:93:52:C5:FC:BB:E7:CE Source BDR JKS content: Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
servercert, Jan 16, 2020, PrivateKeyEntry,
Certificate fingerprint (SHA1): D8:41:3A:3E:D8:9B:81:0E:D8:49:F7:3E:F1:93:52:C5:FC:BB:E7:CE
cmprod.company.co.id, Jan 16, 2020, trustedCertEntry,
Certificate fingerprint (SHA1): D8:41:3A:3E:D8:9B:81:0E:D8:49:F7:3E:F1:93:52:C5:FC:BB:E7:CE While on truststore on each cluster CM, entries with same Certificate fingerprint (SHA1) were found also : Target BDR truststore jssecacerts content: rootca, Jan 16, 2020, trustedCertEntry,
Certificate fingerprint (SHA1): D8:41:3A:3E:D8:9B:81:0E:D8:49:F7:3E:F1:93:52:C5:FC:BB:E7:CE Source BDR truststore jssecacerts content: rootca2, Dec 20, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): D8:41:3A:3E:D8:9B:81:0E:D8:49:F7:3E:F1:93:52:C5:FC:BB:E7:CE For another background, the process of setting TLS/SSL on both cluster are a bit different from Cloudera docs. Since the cluster share the same domain and security team already had signed certificate from trusted CA, we were provided with signed wildcard certificate in .PEM and . KEY files. so instead of generate JKS file from Java keytool on Cloudera nodes, we executes this steps : Create p12 file by combining signed certificate CA from root to local PEM files with corresponding KEY files (openssl pkcs12 -export command) Convert p12 file to JKS file with name of each hostname (keytool -importkeystore -destkeystore command) Import the root CA certificate into the JDK truststore jssecacerts (keytool -importcert command) Also another question, is BDR are sufficient with Level 1: Encryption only TLS/SSL setup on both cluster or is it require more (Level 2 :server-side certificate validation or even Level 3: dual certificate validation)? Many thanks, Al
... View more
05-18-2020
08:40 PM
Realizing I didn't close this off. The suggestions in this post worked perfectly to move me along and eventually setup full TLS encryption. Thanks very much guy's for the help. Very much appreciated!
... View more
05-11-2020
08:52 PM
Hi Team, We are also facing similar issues. Traceback (most recent call last): File "/opt/cloudera/cm-agent/lib/python2.6/site-packages/cmf/agent.py", line 1525, in handle_heartbeat_response self._handle_heartbeat_response(response) File "/opt/cloudera/cm-agent/lib/python2.6/site-packages/cmf/agent.py", line 1658, in _handle_heartbeat_response self._update_parcel_activation_state(response) File "/opt/cloudera/cm-agent/lib/python2.6/site-packages/cmf/agent.py", line 1569, in _update_parcel_activation_state manage_old_parcels = old_response.get("create_parcel_symlinks") AttributeError: 'NoneType' object has no attribute 'get' Tried to hard restart the agent, but no luck. Could anyone help?
... View more
05-09-2020
09:58 AM
I did the following steps and it helped 1) [root@cm_scm_103 cloudera-scm-agent]# cp /opt/cloudera/parcel-repo/STREAMSETS_DATACOLLECTOR-3.14.0-el7.parcel.torrent /opt/cloudera/parcel-cache/ [root@cm_scm_103 cloudera-scm-agent]# ls -ltr /opt/cloudera/parcel-cache/STREAMSETS_DATACOLLECTOR-3.14.0-el7.parcel.torrent -rw-r----- 1 root root 211751 May 9 11:14 /opt/cloudera/parcel-cache/STREAMSETS_DATACOLLECTOR-3.14.0-el7.parcel.torrent You have mail in /var/spool/mail/root [root@cm_scm_103 cloudera-scm-agent]# 2) make sure enough free space in /opt/cloudera/parcels 3) Restarted cloudera-scm-agent in server_b01, server_b02 and cm_scm_103 [root@server_b01 parcel-cache]# systemctl restart cloudera-scm-agent 4) Restarted cloudera-scm-server in cm_scm_103 [root@cm_scm_103 cloudera-scm-agent]# sudo service cloudera-scm-server restart
... View more
04-24-2020
02:30 PM
@bgooley In CDH 6.3.x, this appears to have changed and the "https.py" file is slightly different now. It accepts the cipher_list as a configuration item. The way we secured Port 900 is by doing these steps: 1) Check to see if RC4 (and other weak ciphers) are open on Port 9000: openssl s_client -cipher RC4 -connect <server>:9000 -msg 2) Edit the "/etc/cloudera-scm-agent/config.ini" file 3) Under the "[Security]" section of the config.ini file, we added these lines: # Custom Cipher List to close vulnerabilities for port 9000 cipher_list=HIGH:!DSS:!DH:!ADH:!DES:!3DES:!SHA1:!RC4:!aNULL:!eNULL:!EXPORT:!SSLv2:!SSLv3:!TLSv1 4) Restart the Cloudera CM-Agent: sudo service cloudera-scm-agent restart 5) Wait a minute or so and then rerun the OpenSSL command and RC4 (and other weak ciphers, if you test them) are closed: openssl s_client -cipher RC4 -connect <server>:9000 -msg It would be great if Cloudera could add this to their documentation on how to add this additional security to the CM Agent.
... View more
03-31-2020
02:38 PM
1 Kudo
Ok we finally got it. The downside is that when setting the hadoop.security.group.mapping.ldap.bind.password.file property, it did not update the core-site.xml file. Perform the following procedure: https://community.cloudera.com/t5/Community-Articles/Secure-LDAP-bind-password-in-Hadoop-Configuration/ta-p/247789 And add the property in Cluster-wide Advanced Configuration Snippet (Safety Valve) for core-site.xml of hdfs in cloudera manager Thank you very much @bgooley for your help
... View more
03-05-2020
12:20 PM
@scottwong,
The thread you've posted your question to was marked 'Solved' quite a while ago and hasn't had any activity recently. You would have a better chance of receiving a satisfactory resolution by posting a new question. This will also provide the opportunity to provide details specific to what you are attempting to do that could aid other community members in providing a more tailored answer to your issue.
... View more
01-07-2020
11:24 AM
My vm host system is UBUNTU 18.04, I did the following to fix the problem: 1. vi /etc/cloudera-scm-agent/config.ini server_host = (my master host's ip address) 2. run: getenforce, if the result is disabled, the go ahead, otherwise run: setenforce=0 3. disable firewalls systemctl stop firewalld systemctl disable firewalld systemctl ufw firewalld systemctl ufw firewalld 4. check if networking service is running, if not, start it: systemctl start networking (or run /etc/init.d/networking start) Good luck!
... View more
12-16-2019
01:01 PM
1 Kudo
@VijayM, It seems when I posted, my smiley after "that was quite a gap in our conversation" disappeared. I wanted to be sure you knew it was supposed to be there 🙂
... View more