@A. Karray You can specify JARs to use with Livy jobs using livy.spark.jars in the Livy interpreter conf. This should be a comma separated list of JAR locations which must be stored on HDFS. Currently local files cannot be used (i.e. they won't be localized on the cluster when the job runs.) It is a global setting so all JARs listed will be available for all Livy jobs run by all users. ... View more

@vamsi valiveti 1) 'show tables;' is the standard SQL way of getting table names. '!tables' is specific to Beeline so use 'show tables;' to make sure your SQL is portable to other SQL clients. 2) Use '!sh <command>' to run shell command, e.g. 0: jdbc:hive2://hdp224.local:10000/default> !sh hdfs dfs -ls / Found 9 items drwxrwxrwx - yarn hadoop 0 2016-11-01 14:07 /app-logs drwxr-xr-x - hdfs hdfs 0 2016-11-01 12:41 /apps drwxr-xr-x - yarn hadoop 0 2016-11-01 15:55 /ats drwxr-xr-x - usera users 0 2016-11-01 14:29 /data drwxr-xr-x - hdfs hdfs 0 2016-11-01 12:38 /hdp drwxr-xr-x - mapred hdfs 0 2016-11-01 12:38 /mapred drwxrwxrwx - mapred hadoop 0 2016-11-01 12:38 /mr-history drwxrwxrwx - hdfs hdfs 0 2016-11-01 15:56 /tmp drwxr-xr-x - hdfs hdfs 0 2016-11-01 14:06 /user ... View more

@Roger Young Assuming you are running Ambari as 'root' it will be in ~root/.ssh/id_rsa. If you're running Ambari as a non-root user you will need to set up passworldless SSH for that user so the file will be ~<username>/.ssh/id_rsa. ... View more

@Pooja Kamle Ranger policies are not applied to Hive CLI which is old technology and may be phased out in the future. You should be using Beeline/JDBC/ODBC to connect to Hiveserver2. ... View more

@Anders Boje Larsen Deny policies are only enabled for service definitions that have property enableDenyAndExceptionsInPolicies = true and are off by default for all services. You'll need to update the service definitions for the services you want deny policies for. This page has the required information: Deny-conditions and excludes in Ranger policies ... View more

@Adi Jabkowsky The reason that the users need to exist on the OS (or for you to use Hadoop Group Mapping) is that it is the Hiveserver2 process that gets the username and looks up the groups that user is a member of. It then passes the username and its group membership list to the Ranger Hive plugin (which runs in a thread in the Hiveserver2 process) and this uses the user details to check against a cache of the policies defined for Hive. It is important to understand that the Ranger Hive plugin does not communicate back to the Ranger Admin component during this authorization process. If it did it would be much slower and would make Ranger Admin a single point of failure. When you synchronize your Active Directory users to Ranger using Ranger UserSync, this is only to allow you to add the users and groups to policies in the Ranger Admin UI, it doesn't then make those users available on the cluster itself. You either need to integrate the OS with Active Directory or use the Hadoop Group Mapping feature to make the users and groups available. ... View more