UPDATE: One possible workaround to suppress these quotes from displaying in select * is to create a view like below in Impala:   CREATE VIEW db1.view1 AS SELECT replace(table1.quotedcol1, '"', '') quotedcol1, replace(table1.quotedcol2, '"', '') quotedcol2 FROM db1.table1;   ... View more

Impala doesnt support the ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde' even in newer version like v3.4.0. Any other option to remove double quotes in the output from Impala where the input csv file has quotes? ... View more

Thanks for the info we will try to remove Activity Monitor. Cloudera should have automatically removed AM during upgrade to 7.x if deprecated as promised.  ... View more

Hello @MahendraDevu Did you resolve the error in HUE SAML we are getting this in CDP 7.1.7 after upgrade. SAML was working in CDH5.16 HUE before upgrade: [05/Apr/2019 16:37:03 -0400] views ERROR SAML Identity Provider is not configured correctly: certificate key is missing!   UPDATE: Resolved this issue by making the IDP <md:EntityDescriptor entityID same as that on the metadata.xml we specified in HUE Advanced Configuration snippet hue_safety_valve.ini metadata_file . There was a mismatch between IDP value and what was in the metadata file.  ... View more

After openjdk 1.8.0.292 install we had to fix the mysql scm database ssl connection issue using the property useSSL=false like com.cloudera.cmf.orm.hibernate.connection.url=jdbc:mysql://<mysql-host>/scm?useUnicode=true&characterEncoding=UTF-8&useSSL=false Now same ssl connection issue is happening for nav, navms, amon, rman databases and these components wont start. Can we set the useSSL for these databases also in /etc/cloudera-scm-server/db.properties file like below: com.cloudera.cmf.orm.hibernate.connection.url=jdbc:mysql://localhost/nav?useUnicode=true&characterEncoding=UTF-8&useSSL=false com.cloudera.cmf.orm.hibernate.connection.url=jdbc:mysql://localhost/navms?useUnicode=true&characterEncoding=UTF-8&useSSL=false com.cloudera.cmf.orm.hibernate.connection.url=jdbc:mysql://localhost/rman?useUnicode=true&characterEncoding=UTF-8&useSSL=false ... View more

Yes /etc/krb5.conf was the issue in the destination TST cluster. Specifically the [domain_realm] section did not have proper mapping for the replication source prod hosts and the prod realm. Since the PRD and TST hosts were all in the same domain so it was not easy to map the domain and realm using just the .proddomainxyz.com = PRODREALM . Instead we had to specify the individual source prod hosts in the destination TST /etc/krb5.conf file as below: [domain_realm] prodhostxx1 = PRODREALM prodhostxx2 = PRODREALM prodhostxx3 = PRODREALM etc. specify all the source prod hosts here If we don't specify the prodhosts like above replication doesn't know how to map the prodhosts to the PRODREALM and picks up the default TSTREALM which is why the original wrong realm error happened. Thanks! ... View more

Hi ,  Thanks for the response. It turns out my issue is slightly different. I have been able to unblock myself by creating a new pem key and cert file using openssl.    Thanks for you help, please don't keep the issue open on my part,   Best regards Darren ... View more

@JasonBourne - if you have the same issue, here's a GitHub issue discussing it and linking to a pull request to fix it: https://github.com/cloudera/thrift_sasl/issues/28 You can see in the commits (here: https://github.com/cloudera/thrift_sasl/commits/master), they are testing a new release for a fix, but it looks like it's not quite done yet. Hopefully soon. ... View more

Hi, I get the same issue with DBeaver and with Java.   ... View more