The API Explorer under 'CM => Support => API Explorer' can help you create the CM API to export the CM Audit logs.  Once you are in the Cloudera Manager API page, click on 'GET /audits', then click 'Try it out', and click 'Execute' below.  This will give you a curl command, request url, as well as the response body.  You can change the parameters to filter the results. ... View more

When Sqoop2 starts, it copies /usr/share/java/oracle-connector-java.jar to /var/lib/sqoop2/. Please rename ojdbc6.jar to oracle-connector-java.jar, change the owner and group to sqoop2 and restart Sqoop2. Also, please use oracle.jdbc.OracleDriver as the JDBC Driver Class. ... View more

1) How will this work when we want to change the existing AD domain in CDH v5.3 via CM?   Navigate to the Administration > Settings > Kerberos > "Kerberos Security Realm " setting and set it to the new REALM name. This will clear the collection of principal entries in the cloudera manager "SCM" database, but leaves the entries in AD. We suggest the entries in AD should be deleted as well.   2) What happens to the LDAP users currently setup in Hue? Will they automatically get wiped out?   Actually the users in hue are in a database locally and are mapped through the hue configuration against the target AD service, resolving the sAMAccountName attribute to the hue user and group db values. It should continue to work, make a backup of the hue database file (described in our docs) unless you configured the hue db against a production db server (like postgres, or mysql or oracle).   3) Is there another wizard-driven method to change the AD domain so we know the service principals get setup correctly?   Yes per above comments;     i.) stop cluster services (CDH and CM management services)     ii.) delete cluster kerberos principals from AD suffix you are in via AD administrative UI or pre-created ldapdelete script to remove entries (better to have AD admin remove them)     iii.) change the "Kerberos Security Realm" value from the CM > Administration > Settings > Kerberos > screen (this clears the CM db merged keytab and credentials tables)     iv.) We suggest also deleting the CM Kerberos Account Manager user and re-creating it, and assigning the add/delete/modify rights for user accoungs against the OU to agin based on our docs).     v.) At that point you would "Import Kerberos Account Manager Credentials" again for the new REALM.     vi.) navigate to Administration > Kerberos > Credentials (top of navigation) and click "generate credentials" and it should properly re-generate your CM credentials.   The actual AD entry for each cluster service principal is reflected in the servicePrincipalName entry in the form of [service]/[host.fqdn.name] and in the userPrincipalName entry in the form of [service]/[host.fqdn.name]@[AD.DOMAIN.AS.REALM]   We recommend you clear out the existing cluster principals. You will need to review either updating the CM user's entries userPrincipalName value if its not automatically done by AD, or delete and re-create the user and assign rights to the suffix to that new version of the CM user. The standing academic question is; does the AD service update all userPrincipalName entries to reflect the new domain name as the uppercase realm name? That would introduce a second possible scenario of editing the entries and trying to get CM to regenerate the credentials, but that has a lower rate of success. Its easier to clear and generate new than attempt to sync existing with the SCM db's credentials and merged keytab tables. ... View more