Technically, step 3 and step 4 are mutually exclusive. If you're using the Java cacerts then you don't need to set up a truststore for Ranger and vice-versa. If doing step 3, make sure you update the correct Java cacerts as the Ranger JVM is started with just the command 'java' (not the full path to java) so if you have both OpenJDK and Oracle JDK installed and your Hadoop JAVA_HOME is set to the Oracle JDK, Ranger will actually be started with OpenJDK if /etc/alternatives has not been updated. Also, 'rangertruststore' should probably be called 'rangertruststore.jks' for consistency. ... View more

@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

@shashi kumar The URL looks okay - try doing a curl directly to the ResourceManager (i.e. without Knox) to verify that it is working as expected. This will eliminate YARN as the issue. The error 'SSL23_GET_SERVER_HELLO:unknown protocol' looks like there is an issue establishing an SSL connection to Knox so I think this is the source of your issue. Check that the Knox server is set up correctly and all the certificates are working properly. ... 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