Member since
09-23-2013
238
Posts
72
Kudos Received
28
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1845 | 08-13-2019 09:10 AM | |
3253 | 07-22-2015 08:51 AM | |
7159 | 06-29-2015 06:43 AM | |
5015 | 06-02-2015 05:17 PM | |
20992 | 05-23-2015 04:48 AM |
08-19-2014
11:07 AM
these are false-positive error messages they can be ignored: [18/Aug/2014 09:57:08 -0700] kerberos_ ERROR handle_other(): Mutual authentication unavailable on 200 response [18/Aug/2014 09:57:08 -0700] kerberos_ ERROR handle_other(): Mutual authentication unavailable on 200 response [18/Aug/2014 09:57:08 -0700] kerberos_ ERROR handle_other(): Mutual authentication unavailable on 200 response [18/Aug/2014 09:57:11 -0700] kerberos_ ERROR handle_other(): Mutual authentication unavailable on 200 response [18/Aug/2014 09:57:41 -0700] kerberos_ ERROR handle_other(): Mutual authentication unavailable on 200 response What is the actual error (other than that log message that can be ignored), are you not able to access/use services? did you examine how the principals were created with the getprinc subcommand of kadmin.local?
... View more
08-18-2014
05:56 PM
We provide example kdc.conf and krb5.conf here: http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH5/latest/CDH5-Security-Guide/cdh5sg_troubleshooting.html if you us "kadmin.local" and then the "getprinc" command to specifically examine principals in question, it will tell you what properties are set upon creation of the principal. Your krb5.conf needs to provide better ticket and renew lifetime settings. See the example for guidance. Todd
... View more
08-05-2014
07:16 AM
Hmm, the images are not showing up. I'll check with our forums administrator as to why they are not available and hopefully we can evaluate & reply.
... View more
08-05-2014
06:16 AM
When following our installation documentation, what step did you reach before discovering things were failing? The requirements section of the installation guide is important to review, espectially the networking & security section. http://docs.cloudera.com You should not be laying down all the RPMs, and repo should not be installed manually. Generally speaking you install 1 RPM package, yum install cloudera-manager-server-db-2 It will install its dependancies From there you start the embedded DB (service cloudera-scm-server-db start) Once it completes self-configuration of the DB you should be able to start CM server service cloudera-scm-server start Once you see "Jetty Started" in the logging under /var/log/cloudera-scm-server/cloudera-scm-server.log you can connect to the server. http://your.host.fqdn:7180 From there it will guide you through adding hosts, which will install agent and required JDK. Once that is complete you can start parcel deployment of CM. The "Administration Guide" has the proper steps to "Uninstall", specifically what to do in a failed install attempt. You need to go back through that and verify you cleaned up properly before attempting re-install. Todd
... View more
08-01-2014
05:26 PM
1 Kudo
The keytabs are pushed from a database to a runtime location at startup of services, what you are describing as a configuration is not really viable from what I understand. You will see /var/run/cloudera-scm-agent/process/ but this is ephemeral, next restart will have another locaiton. You could experiment with trying to provide the manual keytabs through safety valve to the necessary services. Todd
... View more
07-24-2014
10:52 AM
What distribution/version of linux are you installing on? We need to look at actual packages installed on your system. The examples below assume you are on a RHEL variant, adjust for debian as necessary. Can you please provide the following: rpm -qa | grep -i hadoop rpm -qa | grep -i hue rpm -qa | grep -i zookeeper rpm -qa | grep -i hive rpm -qa | grep -i cloudera When we are saying "uninstall" we are saying "remove the packages" for For CM/CDH so that you can properly do a parcel based install. Can you please share the URL from our documentation that you are following to uninstall/install as well. Thanks Todd
... View more
07-22-2014
07:28 PM
Mike, Unfortunately there is no magic "ingest CDH only cluster" pre-made toolset that is part of the product. The discrete XML configuration files you have set up for the raw CDH cluster, generally would need to be manually introduced through the CM configuration UI. There was early work attempting to do this, but it was found to not be reliable across the wide variation We do have an API for cloudera manager that allows you to inspect and set cluster configuration values programatically (documented here http://cloudera.github.io/cm_api/apidocs/v6/ and here for examples and historical version reference http://cloudera.github.io/cm_api/). When you consider what is generally "default" for the configuration, most of that is handled by CM, it would be specific non-default settings that you are using in your CDH cluster that would need to be brought over. The API can be used to "dump" the current configuration of the CM database (where config ends up in a CM managed cluster) from a new install to look at what is set by default and compare from a test cluster. THanks Todd
... View more
07-16-2014
12:14 PM
7 Kudos
This is important to understand the difference when using CM vs just CDH. When using Cloudera Manager, configuration is stored in a central DB, upon startup of services on a target cluster node, cloudera manager passes, through the Agent on that host, the runtime configuration that should be used, and starts the processes, pointing to that runtime location. This results in the actual services configuration being stored in a non-standard location of: /var/run/cloudera-scm-agent/process/###-[service]-[SERVICE-ROLE] The most recient 'instance" of a path is the current runtime config (use ls -ltr as root in the /var/run/cloudera-scm-agent/process path, the last being most current. You can access the SAME information on a per service role instance basis, from the "process" tab. For example for hdfs Cloudera Manager > Cluster > HDFS > Instances > (pick for example, the NameNode from the list)> Processes You will see under "Configuration Files/Environment" a greater than (>) that you can click to expand and show all the current configs passed to the server, the same info in the path I describe above. This is handy as not all cluster administrators have root access to get to the indicated path. The cloudera manager function of "Deploy client configuration" pushes the current configuration information, SPECIFIC TO CLIENT APPLICATIONS to the cluster hosts and defined gateway nodes, which end up in the default /etc/ locations you are used to from Hadoop and CDH documentation. Those locations will not have the complete configuration as used by the server, just values necessary for client applications (CLI, custom apps, etc) to use the cluster. Todd
... View more
07-15-2014
10:28 AM
What are you seeing when you run this command on the primary network interface on the system you are seeing errors on and the CM server? ifconfig (interface) For example ifconfig eth0
... View more