@Nigel Jones Ranger is not available to install using the cluster install wizard normally. You have to install the cluster first, then install Ranger once the cluster is up and running. I'm not sure of the exact reason but I suspect it is because it would not be set up properly (users and groups not sync'd, etc.) and then set up of services would fail because of permissions issues. ... View more

@sreehari takkelapati Further to apappu's answer, if you're using an HDP version prior to 2.5.0 then the table you want in Ranger's database is xa_access_audit, but as this is now deprecated and no longer used I wouldn't build any processes around that. Instead you will find that, provided your system is configured correctly, Ranger audit logs will be written to HDFS (under /ranger/audit/<component name>) and/or Solr (in Ambari Infra.) The Solr copy is easy to query to get the results you want provided you know how to write Solr queries, but it only indexes the last 30 days of audit records. The HDFS copy stores all auditing events unless you explicitly delete them. The audit events are stored in JSON format and the fields are fairly self-explanatory. This is an example from Hiveserver2: {"repoType":3,"repo":"hdp250_hive","reqUser":"usera","evtTime":"2016-11-24 04:08:10.179","access":"UPDATE","resource":"z_ssbi_hive_tdzm/imei_table","resType":"@table","action":"update","result":1,"policy":19,"enforcer":"ranger-acl","sess":"b87d8c0e-920f-4a62-8c44-82d7521a1b96","cliType":"HIVESERVER2","cliIP":"10.0.2.36","reqData":"INSERT INTO z_ssbi_hive_tdzm.imei_table PARTITION (partkey\u003d\u00271\u0027)\nSELECT COUNT(*) FROM default.imei_staging_table \nUNION ALL \nSELECT COUNT(*) FROM default.imei_staging_table","agentHost":"hdp250.local","logType":"RangerAudit","id":"d27e1496-08cc-4dad-a6ba-f87736b44a13-26","seq_num":53,"event_count":1,"event_dur_ms":0,"tags":[],"additional_info":"{\"remote-ip-address\":10.0.2.36, \"forwarded-ip-addresses\":[]"} You will need to read these in, parse the JSON and total up the access using a script. It should be fairly easy to write this in something like Perl or Python. ... View more

@Dinesh Das The HDP Sandbox 2.5 comes with Knox that includes a demo LDAP server which should be sufficient for testing purposes. You can start and stop this from Ambari under Knox > Service Actions. In the Knox configuration is a section called 'Advanced users-ldif' which contains the LDIF data loaded by the demo LDAP server. You can add users and groups to this LDIF, save the configuration and then restart the demo LDAP server. If you're not familiar with LDIF then the template to add a user is something like: dn: uid=<username>,ou=people,dc=hadoop,dc=apache,dc=org objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: <common name, e.g. Joe Bloggs> sn: <surname, e.g. Bloggs> uid: <username> userPassword: <password> Replace <username> with the username you want to add, <common name, e.g. Joe Bloggs> with the full name of the user, <surname, e.g. Bloggs> with the surname of the user, and <password> with the password you want. Similarly for groups, use the template dn: cn=<groupname>,ou=groups,dc=hadoop,dc=apache,dc=org objectclass:top objectclass: groupofnames cn: <groupname> member: uid=<username>,ou=people,dc=hadoop,dc=apache,dc=org Replace <groupname> with the group name you want and add and as many of the member: lines as you want to add users to the group, e.g. member: uid=user_a,ou=people,dc=hadoop,dc=apache,dc=org member: uid=user_b,ou=people,dc=hadoop,dc=apache,dc=org member: uid=user_c,ou=people,dc=hadoop,dc=apache,dc=org Configuring your OS to read these users and groups from the demo LDAP server is quite complex - you'll need a lot more information in the LDIF file to support this and to configure PAM/NSS to talk to the LDAP server so for your purposes I'd stick to using 'adduser' and 'addgroup' to add all the users and groups you want to the OS manually. Once you've added the users and groups you want and started the demo LDAP you can use the instructions here to connect Ambari up with the demo LDAP server: https://community.hortonworks.com/questions/2838/has-anyone-integrated-for-demo-purposes-only-the-k.html For Ranger, you should also leave it syncing users from the OS (the default configuration) as you will have used 'adduser' and 'addgroup' to add all the users to the OS so Ranger will automatically sync these for you. If you really want to sync the users from the demo LDAP server then you'll need the set the following properties for Ranger Admin and Ranger Usersync. Note that I haven't tried this so it may not work and you may need to experiment with some of the settings. Ranger: ranger.ldap.base.dn=dc=hadoop,dc=apache,dc=org ranger.ldap.bind.dn=uid=admin,ou=people,dc=hadoop,dc=apache,dc=org ranger.ldap.bind.password=admin-password ranger.ldap.group.roleattribute=cn ranger.ldap.group.searchbase=ou=groups,dc=hadoop,dc=apache,dc=org ranger.ldap.group.searchfilter=(member=uid={0},ou=people,dc=hadoop,dc=apache,dc=org) ranger.ldap.referral=follow ranger.ldap.url=ldap://localhost:33389 ranger.ldap.user.dnpattern=uid={0},ou=people,dc=hadoop,dc=apache,dc=org ranger.ldap.user.searchfilter=(uid={0}) UserSync: ranger.usersync.group.memberattributename=member ranger.usersync.group.nameattribute=cn ranger.usersync.group.objectclass=groupofnames ranger.usersync.group.search.first.enabled=false ranger.usersync.group.searchbase=ou=groups,dc=hadoop,dc=apache,dc=org ranger.usersync.group.searchenabled=true ranger.usersync.group.searchfilter= ranger.usersync.group.searchscope=sub ranger.usersync.group.usermapsyncenabled=true ranger.usersync.ldap.binddn=uid=admin,ou=people,dc=hadoop,dc=apache,dc=org ranger.usersync.ldap.groupname.caseconversion=none ranger.usersync.ldap.ldapbindpassword=admin-password ranger.usersync.ldap.referral=follow ranger.usersync.ldap.searchBase=dc=hadoop,dc=apache,dc=org ranger.usersync.ldap.url=ldap://localhost:33389 ranger.usersync.ldap.user.groupnameattribute=memberof,ismemberof ranger.usersync.ldap.user.nameattribute=uid ranger.usersync.ldap.user.objectclass=person ranger.usersync.ldap.user.searchbase=ou=people,dc=hadoop,dc=apache,dc=org ranger.usersync.ldap.user.searchfilter= ranger.usersync.ldap.user.searchscope=sub ranger.usersync.ldap.username.caseconversion=none ... View more

@Jay SenSharma It's worth pointing out that unless you're using Ranger 0.4 or below, that API is obsolete. You should be using the v2 API linked to by @mvaradkar: https://cwiki.apache.org/confluence/display/RANGER/REST+APIs+for+Service+Definition%2C+Service+and+Policy+Management ... View more

@Pradheep Shan Currently modifying the Grafana dashboards is not supported in Ambari. ... View more

@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

@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