Member since
03-06-2018
8
Posts
0
Kudos Received
2
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
39818 | 03-16-2018 03:38 PM | |
2869 | 03-06-2018 12:15 PM |
11-12-2019
12:23 PM
@cloud123user, Thanks for the kind feedback. I am glad that the solution worked for you!
... View more
11-15-2018
05:59 AM
Hi , I want to install cdh5.15.1 hadoop client on my Ubuntu 16.04 host. I have added the repo url in /etc/apt/sources.list.d/cloudera.list file. How can I specify a particular hadoop-client version in apt-get command. I thought apt-get install hadoop-client=< version > should work. But I am unable to figure out the version number. Here is the link for repo http://archive.cloudera.com/cdh5/ubuntu/xenial/amd64/cdh/pool/contrib/h/hadoop/ Thanks 🙂
... View more
08-22-2018
11:43 PM
@vijithv, First, firewalls can easily block UDP and allow TCP. I mentioned that was a possible cause. Also, depending on how you have your /etc/krb5.conf configured, a different KDC could have been contacted. You can see distinctly in the failure via UDP that there is a socket timeout for each attempt to connect to the KDC. This is a failure at the networking side where a client cannot connect to a server. Since no connection was ever made via UDP, there was no change for it to know to try TCP. That "switching" is done based on a response of KRB5KRB_ERR_RESPONSE_TOO_BIG I believe so if no response is made, no "switching" to TCP will occur. If you really want to get to the bottom of this, recreate the problem while capturing packets via tcpdump like this: # tcpdump -i any -w ~/kerberos_broken.pcap port 88 Then, with the problem fixed reproduce again while capturing packets: # tcpdump -i any -w ~/kerberos_fixed.pcap port 88 Use Wireshark (it does a great job of decoding Kerberos packets) and you will be able to see the entire interaction. This will show us information to help determine the cause. Wireshark is here: https://www.wireshark.org/
... View more
03-06-2018
12:15 PM
The issue is resolved. The exceptions were misleading; the real issue was this: Exception in thread "MainThread" java.lang.IllegalArgumentException: Invalid value set for db.setupType, the valid values are EMBEDDED or EXTERNAL I changed the default value for com.cloudera.cmf.db.sertupType in /etc/cloudera-scm-server/db.properties to EXTERNAL. It was set to INIT.
... View more