Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Thu, 9 Jun 2016 22:49:21 +0000 (UTC)
From: "Robert Ketcherside (JIRA)" <jira@apache.org>
To: issues@ambari.apache.org
Message-ID: <JIRA.12977423.1465512523000.46659.1465512561038@Atlassian.JIRA>
In-Reply-To: <JIRA.12977423.1465512523000@Atlassian.JIRA>
References: <JIRA.12977423.1465512523000@Atlassian.JIRA> <JIRA.12977423.1465512523695@arcas>
Subject: [jira] [Created] (AMBARI-17155) Accumulo Tracer principal causes
 OneFS permissions conflict
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 09 Jun 2016 22:49:22 -0000

Robert Ketcherside created AMBARI-17155:
-------------------------------------------

             Summary: Accumulo Tracer principal causes OneFS permissions conflict
                 Key: AMBARI-17155
                 URL: https://issues.apache.org/jira/browse/AMBARI-17155
             Project: Ambari
          Issue Type: Bug
          Components: ambari-server
    Affects Versions: 2.2.2
         Environment: Ambari 2.2.2, HDP 2.4.2, OneFS 8.0.0.1
            Reporter: Robert Ketcherside
            Priority: Minor


The default principal for trace.user (tracer-${cluster-name}@${realm}) causes Accumulo Tracer to be unable to start once Kerberos is enabled in an environment where the NameNode and DataNode are an EMC/Isilon OneFS cluster.

Unlike the Apache NameNode, OneFS doesn't have a user-defined auto_to_local mapping for principals to local users. It just takes the root of the principal and looks for a local user of the same name.

Tracer uses its upn in order to auth to hdfs and read the value of the file within the "instance_id" directory, and the name of the directory within "version" under apps/accumulo/data. If these steps fail, the component dies.

Currently Isilon is advising customers to switch the principal name to ${accumulo-env/accumulo_user}@${realm}. The Accumulo user already has read access to the contents of the data directory. (Hence, this issue is filed as minor; there is a work around.) 

An admin could also resolve the permissions issue for the tracer principal by giving o+r permissions recursively to the accumulo directory; or by creating a tracer user, adding it to a group like hadoop, and changing group ownership of the apps/accumulo direcotry to o+r recursively.

I'm filing this JIRA to ask for a resolution to be investigated on the Apache side. Here are a few ideas, though they might not be valid courses of action:
- Use an Accumulo upn or spn for kerberized trace.user. SPN is indicated as default in the Accumulo manual, https://accumulo.apache.org/1.7/accumulo_user_manual#_kerberos .
- Have Accumulo Tracer check hdfs as a different principal.
- Remove Accumulo Tracer's requirement to read information from the file system as a prerequisite to service start.

See https://community.emc.com/community/products/isilon/blog/2016/06/03/onefs-ambari-and-accumulo-tracer for more details.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)