Hello @kavitha_p    We use SSO so all authentication for customers, partners, employees, and community users is handled through your MyCloudera account.  When you first sign up for the Community, you create a MyCloudera account, then when you choose your community username the Cloudera Community account is created.   Only a small part of your MyCloudera profile is copied to your community account and this information is kept private.   Only your username and registration date are visible to other users unless you add more information to your Community profile.     To access your MyCloudera profile, you use the "person" icon in the upper right corner:   From there you should be able to edit your Job info, including your Company:     You can edit your community information by going to the community home page and clicking on your user icon in the right column and select "My Settings"   From your community settings you can customize some of your personal information you wish to share on the community such as your About (biography), Location, Personal Website.   Please let us know if you are still unable to change your Company from your MyCloudera Profile.  ... View more

When your first post titled "Ambari-server start error" was caught by the spam filter, you created a second post with the same content.   I approved one of them so we didn't have duplicate questions on the board.   I am unsure why your posts were flagged as spam.  Our Community Admins are still tuning the spam filter rules after merging into the Unified Cloudera Community.   Our moderators will get posts out of spam quarantine as quickly as we are able.  I apologize again for the inconvenience.   ... View more

Since you were able to access the Cloudera repo, you should be able to install the Oracle JDK on the agent with:     sudo apt-get install oracle-j2sdk1.8   If that does not work, you can install it with the instructions under Manually Installing OpenJDK   When starting, the agent looks through common paths for JDKs and will select the Oracle 1.8 JDK first if it finds it.   If you would prefer to use OpenJDK on all the systems, in Cloudera Manager navigate to Hosts > Hosts Configuration and set the Java Home Directory to your preferred JAVA_HOME. ... View more

The log shows the Cloudera repo is being installed, but the 'apt-get update' does not show the cloudera-manager repo being referenced.   Because the cloudera-manager rep is not indexed, the attempt to install the cloudera-manager-agent fails.   Could you check that the repo file "cloudera-manager.list" was correctly installed by the script.  I believe it would be located under /etc/apt/sources.list.d.   Also check that your system can reach archive.cloudera.com (the repo is under http://archive.cloudera.com/cm6/) and is not blocked by corporate, cloud, or local firewall rules. ... View more

This is a Kerberos configuration issue, most likely with the principal for the second NameNode.  When a checkpoint is attempted (copying the fsimage file from the Standby NameNode to the Active), the connection is failing due to the GSSAPI authentication with the Kerberos credential.   The failover controller logs will probably contain similar messages.   Since the server is able to start, your basic Kerberos setup is allowing the server to obtain it's initial credential but it appears it is expiring.   A few possible causes:   * The principal needs to have renewable tickets.  In your output this is set to false.  The problem could be with the /etc/krb5.conf file on the Standby or with the principal in your KDC.   * Reverse DNS lookup for the hostname is not working.  The packet sent from one server has the information "my hostname is:  server2.example.com, IP: 10.1.2.3".  The source does a reverse DNS lookup for 10.1.2.3 and is not receiving a hostname or is receiving a hostname that does not match the one provided.   * You are having an intermittent outage with your KDC or DNS that is causing the above mentioned problems.   Depending upon the type of KDC in use and how it is configured, there may be additional issues.   Since you report the rest of the cluster is functional (no loss to the DataNodes), this is most likely isolated to the one NameNode's principal.  ... View more

To begin with, my explanation will cover the case that you are using simple authentication and the default Hadoop group mappings. Hadoop does not use uid or gid. You username on the system is passed to the namenode when you make a client call. hadoop fs -ls / If your username is 'bob', the NameNode will receive the string "bob" to identify you. If your username is 'hdfs', the NameNode will receive the string "hdfs" to identify you. User and Group lookups are done by the NameNode. The default for the property hadoop.security.group.mapping is org.apache.hadoop.security.ShellBasedUnixGroupsMapping, which means a username passed with an HDFS client API will do the equivalent of "id -Gn " on the NameNode host. On the host running the NameNode, use the standard unix commands to assign users to groups. $ sudo usermod -G developer Peter You only need to define the group membership on the NameNode's host operating system. Now if a user named 'Peter' exists on any other system configured as an HDFS client, they will still be considered part of the "developer" group by HDFS. "hdfs groups " is a handy command you can run to see if a user belongs to a group in HDFS Create your directory in HDFS: hadoop fs -mkdir /projects/only/developers hadoop fs -chown anyuser:developers /projects/only/developers hadoop fs -chmod 775 /projects/only/developers Your directory is now writable by anyone in the group "developers" as defined on the NameNode. ... View more