Member since
10-01-2018
110
Posts
3
Kudos Received
4
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 1494 | 09-02-2021 08:55 AM | |
| 3280 | 10-15-2019 10:42 AM | |
| 3840 | 10-09-2019 05:46 AM | |
| 1298 | 10-09-2019 04:19 AM |
09-02-2021
08:59 AM
you should "kinit" with your workload user credentials in CDP.before running any Hadoop commands
... View more
10-18-2019
09:07 AM
Thanks bantone for your article
... View more
10-16-2019
03:49 AM
Hi Sandeep, Can you please check the owner and permissions of "/var/run/cloudera-scm-server" properties whether it is root or cloudera-scm ?? Thanks and Regards, Bhuvan.
... View more
10-15-2019
10:42 AM
1 Kudo
Hi Baris, Yeah, you were correct there won't be any issue having those checks failed in worker nodes. When you ran CDSW status commands the following checks are useful in Master node like ingress controller which is required in your master node and run as part of the Kube-controller-manager binary. Failing these checks in your worker node will not cause you problems. Regards, Bhuvan
... View more
10-09-2019
05:46 AM
1 Kudo
Hi Please check if you have faced any errors like below in the CDSW logs like below after upgrade to 1.6 ERROR EngineInit.BrowserSvcs fgtugi359w4b5n58 Finish apiGet, failed to execute API request data = {"err":"Get https://cdsw.unedic.intra/api/v1/projects/Priseenmain/formation_python/engines/fgtugi359w4b5n58/permissions?user=kkhataei-ext: x509: certificate signed by unknown authority","user":"root"} The method by which the Cloudera Data Science Workbench web UI session tokens are stored has been hardened. https://www.cloudera.com/documentation/data-science-workbench/latest/topics/cdsw_release_notes.html#rel_160 as the issue happened after the upgrade to CDSW 1.6 I suspect that it is related to the issue addressed under "DSE-7173". It seems that in CDSW 1.6 all internal traffic is et to go through the ingress-controller proxy for more security, however, it seems that some certificates are not making it into the sessions A possible solution can be by manually copy the root CA and intermediate CA into the underlying cert file that contains all of the OS level certs. Check if below steps works Please find the steps below, try it and let us know how it goes. 1. Copy all of the certificates you are using in your chain of trust (root CA, intermediate CA's). It should start and end with ----BEGIN CERTIFICATE----, ----END CERTIFICATE----) 2. Create a session like normal and copy the engineID from the URl. Then figure out which host the pod is running on (last column) with: # kubectl get po --all-namespaces=true -o wide 3. SSH into that host and run: docker ps | grep -i <engineID> (to get the container id) docker cp <containerID>:/etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt This step will copy the ca-certificate file out of the docker container. This file contains all of the certificates that are trusted by the OS. 4. Append ALL of your internal root CA / intermediate CA certificates to the end of this file. Copy this file to all of the CDSW nodes that you have 5. Go back to CDSW -> Admin -> Engines, and under Mounts, add /etc/ssl/certs/ca-certificates.crt to the engine mount. This will ensure that the changes persist across restarts. 6. Create a brand new session in CDSW and ensure that you can open the _Terminal and access Jupyter workbench.
... View more
10-09-2019
04:19 AM
Hi Yes, your understanding of adding an existing SCM host to the new cluster is correct. We won't recommend you to add the new cluster with existing SCM hosts. https://docs.cloudera.com/documentation/enterprise/5-14-x/topics/cm_mc_add_delete_cluster.html#cmug_topic_6_1__section_klz_tj4_fn Regards, Bhuvan
... View more