Header Shadow Image


There is a problem processing audits for HIVESERVER2.

Getting this?

There is a problem processing audits for HIVESERVER2.

[02/Sep/2019 12:36:30 +0000] 32165 Audit-Plugin throttling_logger ERROR    (341 skipped) Error occurred when sending entry to server: [02/Sep/2019 12:36:30 +0000] 32165 Audit-Plugin throttling_logger INFO     (341 skipped) Unable to send data to nav server. Will try again.

Diggig further, we see this error as well:

[02/Sep/2019 11:31:55 +0000] 4044 Profile-Plugin navigator_plugin INFO     Pipelines updated for Profile Plugin: set([])
[02/Sep/2019 11:31:55 +0000] 4044 Audit-Plugin navigator_plugin_pipeline INFO     Starting with navigator log None for role HIVESERVER2 and pipeline HiveSentryOnFailureHookTP
[02/Sep/2019 11:31:55 +0000] 4044 Metadata-Plugin navigator_plugin ERROR    Exception caught when trying to refresh Metadata Plugin for conf.cloudera.spark_on_yarn with count 0 pipelines names [].
Traceback (most recent call last):
  File "/opt/cloudera/cm-agent/lib/python2.7/site-packages/cmf/audit/navigator_plugin.py", line 198, in immediate_refresh
    self._recreate_pipelines_for_csd()
  File "/opt/cloudera/cm-agent/lib/python2.7/site-packages/cmf/audit/navigator_plugin.py", line 157, in _recreate_pipelines_for_csd
    existing_logs = [name for name in os.listdir(self.nav_conf.log_dir)
AttributeError: 'NoneType' object has no attribute 'log_dir'
[02/Sep/2019 11:31:55 +0000] 4044 Metadata-Plugin navigator_plugin INFO     Pipelines updated for Metadata Plugin: []

Redeploying the Spark config should solve this:

Execute DeployClusterClientConfig for {yarn,solr,hbase,kafka,hdfs,hive,spark_on_yarn} in parallel.

We can only surmise what may have occurred in this case.  Apparently config updates were being done to the config while an earlier config deployment was happening, corrupting the setup.  This may not solve it, however.  YMMV.  

In all likelihood, your free license has expired.  In that case navigate to Cloudera Management Service then turn off / uncheck the following:

Navigator Audit Server Role Health Test

But that wasn't it either.  Finally, remove the Navigator Audit Server from Cloudera Management Services instances since no valid license exists.

Cheers,
TK

How do I connect to HiveServer2 (HS2) through beeline

How do I connect to HiveServer2 (HS2) through beeline:

beeline> !connect jdbc:hive2://cm-r01en01.mws.mds.xyz:10000/default;principal=hive/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ
Connecting to jdbc:hive2://cm-r01en01.mws.mds.xyz:10000/default;principal=hive/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ
Connected to: Apache Hive (version 2.1.1-cdh6.3.0)
Driver: Hive JDBC (version 2.1.1-cdh6.3.0)
Transaction isolation: TRANSACTION_REPEATABLE_READ
0: jdbc:hive2://cm-r01en01.mws.mds.xyz:10000/>
0: jdbc:hive2://cm-r01en01.mws.mds.xyz:10000/>
0: jdbc:hive2://cm-r01en01.mws.mds.xyz:10000/> show tables;
INFO  : Compiling command(queryId=hive_20190902102937_4ef97c5b-19ff-47b8-be81-dacb2edeece0): show tables
INFO  : Semantic Analysis Completed
INFO  : Returning Hive schema: Schema(fieldSchemas:[FieldSchema(name:tab_name, type:string, comment:from deserializer)], properties:null)
INFO  : Completed compiling command(queryId=hive_20190902102937_4ef97c5b-19ff-47b8-be81-dacb2edeece0); Time taken: 2.67 seconds
INFO  : Executing command(queryId=hive_20190902102937_4ef97c5b-19ff-47b8-be81-dacb2edeece0): show tables
INFO  : Starting task [Stage-0:DDL] in serial mode
INFO  : Completed executing command(queryId=hive_20190902102937_4ef97c5b-19ff-47b8-be81-dacb2edeece0); Time taken: 1.333 seconds
INFO  : OK
+———–+
| tab_name  |
+———–+
+———–+
No rows selected (5.048 seconds)
0: jdbc:hive2://cm-r01en01.mws.mds.xyz:10000/> show databases;
INFO  : Compiling command(queryId=hive_20190902103034_18cb927f-0ab7-4a2d-b311-206b6ebb2cc2): show databases
INFO  : Semantic Analysis Completed
INFO  : Returning Hive schema: Schema(fieldSchemas:[FieldSchema(name:database_name, type:string, comment:from deserializer)], properties:null)
INFO  : Completed compiling command(queryId=hive_20190902103034_18cb927f-0ab7-4a2d-b311-206b6ebb2cc2); Time taken: 0.059 seconds
INFO  : Executing command(queryId=hive_20190902103034_18cb927f-0ab7-4a2d-b311-206b6ebb2cc2): show databases
INFO  : Starting task [Stage-0:DDL] in serial mode
INFO  : Completed executing command(queryId=hive_20190902103034_18cb927f-0ab7-4a2d-b311-206b6ebb2cc2); Time taken: 0.039 seconds
INFO  : OK
+—————-+
| database_name  |
+—————-+
| default        |
+—————-+
1 row selected (0.362 seconds)
0: jdbc:hive2://cm-r01en01.mws.mds.xyz:10000/>

 

Cheers,
TK

Required executor memory (1024), overhead (384 MB), and PySpark memory (0 MB) is above the max threshold (1024 MB) of this cluster!

Getting this?

java.lang.IllegalArgumentException: Required executor memory (1024), overhead (384 MB), and PySpark memory (0 MB) is above the max threshold (1024 MB) of this cluster! Please check the values of 'yarn.scheduler.maximum-allocation-mb' and/or 'yarn.nodemanager.resource.memory-mb'.

Either increase the Container Memory:

yarn.nodemanager.resource.memory-mb to 2GB from 1GB

Or reduce the maximum container memory:

yarn.scheduler.maximum-allocation-mb from 1GB to 512MB

in the YARN configuration settings.  However, you may get this error:

Service ResourceManager failed in state INITED; cause: org.apache.hadoop.yarn.exceptions.YarnRuntimeException: Invalid resource scheduler memory allocation configuration: yarn.scheduler.minimum-allocation-mb=1024, yarn.scheduler.maximum-allocation-mb=512.  Both values must be greater than or equal to 0and the maximum allocation value must be greater than or equal tothe minimum allocation value.

So we can set the container memory minimal to 1/2 the max:

yarn.scheduler.minimum-allocation-mb from 1G to 256MB

But that didn't work.  Ultimately setting this to 2GB worked:

yarn.scheduler.maximum-allocation-mb

Cheers,
TK

 

Cloudera Clusters: Running kinit on a kerberos principal returns with a 1969 date.

Are you getting this result?

[root@cm-r01en01 process]# systemctl restart cloudera-scm-agent
[root@cm-r01en01 process]#
[root@cm-r01en01 process]#
[root@cm-r01en01 process]#
[root@cm-r01en01 process]# kinit -kt ./1401-hdfs-NFSGATEWAY/hdfs.keytab hdfs/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ
[root@cm-r01en01 process]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ

Valid starting       Expires              Service principal
12/31/1969 19:00:00  12/31/1969 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
[root@cm-r01en01 process]#

 

Solve it by restarting nfs-ganesha on the NFS server!   I know what you're saying but keep reading.

Turns out our NFS server was stuck on one of the three cluster nodes making up our NFS cluster.  This affected the cloudera-scm-agent (CMA) . It couldn't properly communicate with or report back to the CMS ( Cloudera Manager Server ).  CMA does FS checks.  It got stuck trying to read the NFS mount.  

Restarting nfs-ganesha allowed NFS reads again.  CMA could then do it's FS checks and report back.  Renewing the ticket after that fixed the above issue:

[root@cm-r01en01 process]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: hdfs/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ

Valid starting       Expires              Service principal
08/31/2019 07:30:14  09/01/2019 07:30:14  krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ
        renew until 09/07/2019 07:30:14
[root@cm-r01en01 process]#

Cheers,
TK

org.apache.hadoop.security.AccessControlException: Client cannot authenticate via:[TOKEN, KERBEROS]

Getting this?

[root@cm-r01en01 ~]# hdfs dfs -ls /
19/08/25 22:43:19 WARN ipc.Client: Exception encountered while connecting to the server : org.apache.hadoop.security.AccessControlException: Client cannot authenticate via:[TOKEN, KERBEROS]
ls: Failed on local exception: java.io.IOException: org.apache.hadoop.security.AccessControlException: Client cannot authenticate via:[TOKEN, KERBEROS]; Host Details : local host is: "cm-r01en01.mws.mds.xyz/192.168.0.140"; destination host is: "cm-r01nn02.mws.mds.xyz":8020;
[root@cm-r01en01 ~]#

Fix it by doing the following:

  • Ensure the following setting is commented out and following two settings exist in the krb5.conf:

    # default_ccache_name = KEYRING:persistent:%{uid}

    renew_lifetime = 7d
    forwardable = true

  • Stop the cluster and CM.

  • Regenerate the Cluster Kerberos Credentials in AdministrationSecurity.

  • Start CM and CDH services.

  • Try the procedure again.

Try the operation again:

[root@cm-r01en01 ~]# ls -altri /var/run/cloudera-scm-agent/process/*hdfs*/hdfs.keytab
   40996 -rw——-. 1 hdfs hdfs 534 Aug 25 01:58 /var/run/cloudera-scm-agent/process/1016-hdfs-NFSGATEWAY/hdfs.keytab
   57096 -rw——-. 1 hdfs hdfs 534 Aug 25 02:01 /var/run/cloudera-scm-agent/process/1089-hdfs-NFSGATEWAY/hdfs.keytab
17388393 -rw——-. 1 hdfs hdfs 534 Aug 25 08:48 /var/run/cloudera-scm-agent/process/1174-hdfs-NFSGATEWAY/hdfs.keytab
17814727 -rw——-. 1 hdfs hdfs 534 Aug 25 20:16 /var/run/cloudera-scm-agent/process/1249-hdfs-NFSGATEWAY/hdfs.keytab
17871689 -rw——-. 1 hdfs hdfs 534 Aug 25 21:29 /var/run/cloudera-scm-agent/process/1329-hdfs-NFSGATEWAY/hdfs.keytab
[root@cm-r01en01 ~]# kinit -kt /var/run/cloudera-scm-agent/process/1329-hdfs-NFSGATEWAY/hdfs.keytab hdfs/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ
[root@cm-r01en01 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: hdfs/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ

Valid starting       Expires              Service principal
08/25/2019 22:44:06  08/26/2019 22:44:06  krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ
        renew until 09/01/2019 22:44:06
[root@cm-r01en01 ~]#
[root@cm-r01en01 ~]#
[root@cm-r01en01 ~]#
[root@cm-r01en01 ~]# hdfs dfs -ls /
Found 4 items
drwxr-xr-x   – hbase hbase               0 2019-08-25 21:30 /hbase
drwxrwxr-x   – solr  solr                0 2019-08-13 00:41 /solr
drwxrwxrwt   – hdfs  supergroup          0 2019-08-17 21:28 /tmp
drwxr-xr-x   – hdfs  supergroup          0 2019-08-17 22:38 /user
[root@cm-r01en01 ~]# klist -fe
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: hdfs/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ

Valid starting       Expires              Service principal
08/25/2019 22:44:06  08/26/2019 22:44:06  krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ
        renew until 09/01/2019 22:44:06, Flags: FRIA
        Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
[root@cm-r01en01 ~]#

Note the flags above FRIA.  The R stands for renewable, a requirements for Cloudera.

UNVERIFIED

An alternate solution to this could be to set the following to privacy however we never tried it.  

hadoop.rpc.protection

Cheers,
TK

The readiness of the Impala Daemon to process queries is not known.

Getting this from the Impala Daemon?

The readiness of the Impala Daemon to process queries is not known.

Investigation reveals:

Aug 25 09:16:39 cm-r01wn01 kernel: FINAL_REJECT: IN=eth0 OUT= MAC=00:50:56:86:7e:b7:00:50:56:86:79:2a:08:00 SRC=192.168.0.132 DST=192.168.0.160 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=6227 DF PROTO=TCP SPT=59318 DPT=23000 WINDOW=29200 RES=0x00 SYN URGP=0

Solve it by adding the port to the firewall configuration and distributing it:

[root@awx01 ansible]# grep -Ei 23000 adhoc/public.xml
  <port protocol="tcp" port="23000"/>
  <port protocol="udp" port="23000"/>
[root@awx01 ansible]# ansible cm* -i infra -m copy -a 'src=adhoc/public.xml dest=/etc/firewalld/zones/public.xml'
[root@awx01 ansible]# cd /ansible && ansible 'cm*' -m shell -a 'systemctl restart firewalld';

Cheers,
TK

preauth (encrypted_timestamp) verify failure: Preauthentication failed

Getting this?

Aug 25 08:18:51 idmipa03.mws.mds.xyz krb5kdc[6704](info): preauth (encrypted_timestamp) verify failure: Preauthentication failed
Aug 25 08:18:51 idmipa03.mws.mds.xyz krb5kdc[6704](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.140: PREAUTH_FAILED: hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ for krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ, Preauthentication failed

Check the principal vs the keytab you're using for the same service:

kadmin.local:  getprinc hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ
Principal: hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ
Expiration date: [never]
Last password change: Sun Aug 25 01:14:37 EDT 2019
Password expiration date: [never]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 90 days 00:00:00
Last modified: Sun Aug 25 01:14:37 EDT 2019 (hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ)
Last successful authentication: [never]
Last failed authentication: Sun Aug 25 08:37:15 EDT 2019
Failed password attempts: 31362
Number of keys: 2
Key: vno 22, aes256-cts-hmac-sha1-96:special
Key: vno 22, aes128-cts-hmac-sha1-96:special
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
kadmin.local:

Now check the keytab for the same service:

[root@cm-r01en01 ~]# klist -kte /var/run/cloudera-scm-agent/process/1151-hue-KT_RENEWER/hue.keytab
Keytab name: FILE:/var/run/cloudera-scm-agent/process/1151-hue-KT_RENEWER/hue.keytab
KVNO Timestamp           Principal
—- ——————- ——————————————————
  18 08/25/2019 00:46:12 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (aes256-cts-hmac-sha1-96)
  18 08/25/2019 00:46:12 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (aes128-cts-hmac-sha1-96)
  18 08/25/2019 00:46:12 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (aes256-cts-hmac-sha384-192)
  18 08/25/2019 00:46:12 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (aes128-cts-hmac-sha256-128)
  18 08/25/2019 00:46:12 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (des3-cbc-sha1)
  18 08/25/2019 00:46:12 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (arcfour-hmac)
[root@cm-r01en01 ~]#

To resolve this, go to Cloudera Manager and regenerate the credentials.  New principal looked like this:

kadmin.local:  getprinc hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ
Principal: hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ
Expiration date: [never]
Last password change: Sun Aug 25 08:38:34 EDT 2019
Password expiration date: [never]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 90 days 00:00:00
Last modified: Sun Aug 25 08:38:34 EDT 2019 (hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ)
Last successful authentication: [never]
Last failed authentication: Sun Aug 25 08:37:15 EDT 2019
Failed password attempts: 31362
Number of keys: 6
Key: vno 23, aes256-cts-hmac-sha1-96
Key: vno 23, aes128-cts-hmac-sha1-96
Key: vno 23, des3-cbc-sha1
Key: vno 23, arcfour-hmac
Key: vno 23, camellia128-cts-cmac
Key: vno 23, camellia256-cts-cmac
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
kadmin.local:

kadmin.local:  getprinc hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ
Principal: hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ
Expiration date: [never]
Last password change: Sun Aug 25 08:38:17 EDT 2019
Password expiration date: [never]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 90 days 00:00:00
Last modified: Sun Aug 25 08:38:17 EDT 2019 (hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 6
Key: vno 19, aes256-cts-hmac-sha1-96
Key: vno 19, aes128-cts-hmac-sha1-96
Key: vno 19, des3-cbc-sha1
Key: vno 19, arcfour-hmac
Key: vno 19, camellia128-cts-cmac
Key: vno 19, camellia256-cts-cmac
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
kadmin.local:

Comparing the above to the generated hue.keytab files shows a match:

[root@cm-r01en01 ~]# klist -kte /var/run/cloudera-scm-agent/process/1229-hue-KT_RENEWER/hue.keytab
Keytab name: FILE:/var/run/cloudera-scm-agent/process/1229-hue-KT_RENEWER/hue.keytab
KVNO Timestamp           Principal
—- ——————- ——————————————————
  23 08/25/2019 08:44:22 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (aes256-cts-hmac-sha1-96)
  23 08/25/2019 08:44:22 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (aes128-cts-hmac-sha1-96)
  23 08/25/2019 08:44:22 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (aes256-cts-hmac-sha384-192)
  23 08/25/2019 08:44:22 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (aes128-cts-hmac-sha256-128)
  23 08/25/2019 08:44:22 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (des3-cbc-sha1)
  23 08/25/2019 08:44:22 hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ (arcfour-hmac)
[root@cm-r01en01 ~]#

[root@cm-r01en02 ~]# klist -kte /var/run/cloudera-scm-agent/process/1228-hue-KT_RENEWER/hue.keytab
Keytab name: FILE:/var/run/cloudera-scm-agent/process/1228-hue-KT_RENEWER/hue.keytab
KVNO Timestamp           Principal
—- ——————- ——————————————————
  19 08/25/2019 08:44:22 hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ (aes256-cts-hmac-sha1-96)
  19 08/25/2019 08:44:22 hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ (aes128-cts-hmac-sha1-96)
  19 08/25/2019 08:44:22 hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ (aes256-cts-hmac-sha384-192)
  19 08/25/2019 08:44:22 hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ (aes128-cts-hmac-sha256-128)
  19 08/25/2019 08:44:22 hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ (des3-cbc-sha1)
  19 08/25/2019 08:44:22 hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ (arcfour-hmac)
[root@cm-r01en02 ~]#

And Hue is green.

Cheers,
TK

ERROR    Timed out waiting for worker process collecting filesystem usage to complete.

Getting this error?

==> /var/log/cloudera-scm-agent/cloudera-scm-agent.log <==
[24/Aug/2019 22:00:08 +0000] 3697 Monitor-HostMonitor throttling_logger ERROR    Timed out waiting for worker process collecting filesystem usage to complete. This may occur if the host has an NFS or other remote filesystem that is not responding to requests in a timely fashion. Current nodev filesystems: /dev/shm,/run,/sys/fs/cgroup,/run/cloudera-scm-agent/process,/run/cloudera-scm-agent/process,/run/user/155601104,/n/mds.xyz,/run/user/0
[24/Aug/2019 22:00:08 +0000] 3697 MainThread agent        ERROR    Heartbeating to srv-c01.mws.mds.xyz:7182 failed.

Verify your NFS storage.  In our case one of the gluster brick's was out of space under root:

[root@nfs03 ~]# systemctl restart glusterd haproxy keepalived nfs-ganesha
Job for glusterd.service failed because the control process exited with error code. See "systemctl status glusterd.service" and "journalctl -xe" for details.
[root@nfs03 ~]# df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   41G   41G   20K 100% /

Free the space and restart services.

Cheers,
TK

ERROR:desktop.kt_renewer:Couldn’t renew kerberos ticket in order to work around Kerberos 1.8.1 issue. Please check that the ticket for ‘‘ is still renewable:

Getting this?

INFO:desktop.kt_renewer:Renewing kerberos ticket to work around kerberos 1.8.1: /usr/bin/kinit -R -c /var/run/hue/hue_krb5_ccache
kinit: KDC can't fulfill requested option while renewing credentials
ERROR:desktop.kt_renewer:Couldn't renew kerberos ticket in order to work around Kerberos 1.8.1 issue. Please check that the ticket for 'hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ' is still renewable:
  $ klist -f -c /var/run/hue/hue_krb5_ccache
If the 'renew until' date is the same as the 'valid starting' date, the ticket cannot be renewed. Please check your KDC configuration, and the ticket renewal policy (maxrenewlife) for the 'hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ' and `krbtgt' principals.

Resolve it by adding the following lines to the /etc/krb5.conf file on the KDC servers:

[libdefaults]
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true

Then regenerate the kerberos credentials by browsing to Administration – Security – Kerberos Credentials, checking off all hosts and regenerating the Kerberos Credentails for all.

Once that is done, restart the Kerberos Ticket Renewer.

Didn't work?  Set the Maximum Renewable Life for Principals to 7 days from 5 days and set the Hue Keytab Renewal Interval to 7 days:

Hue Keytab Renewal Interval
reinit_frequency

However this did not work for us either.  The real issue was in this message on the KDC server:

Aug 24 21:26:50 idmipa03.mws.mds.xyz krb5kdc[12023](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.140: TICKET NOT RENEWABLE: authtime 0,  hu /cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ for krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ, KDC can't fulfill requested option

We can see this through the cache:

[root@cm-r01en02 ~]# klist -fe /var/run/hue/hue_krb5_ccache
Ticket cache: FILE:/var/run/hue/hue_krb5_ccache
Default principal: hue/cm-r01en02.mws.mds.xyz@MWS.MDS.XYZ

Valid starting       Expires              Service principal
08/24/2019 21:14:07  08/25/2019 21:14:07  krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ
        Flags: FIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
You have new mail in /var/spool/mail/root
[root@cm-r01en02 ~]#

Hence why when we try to kinit with the ticket, we get the above renewal error message:

[root@cm-r01en01 ~]# kinit -R -c /var/run/hue/hue_krb5_ccache
kinit: KDC can't fulfill requested option while renewing credentials
[root@cm-r01en01 ~]#

It is missing the R ( renewable ) flag .  For this we'll need to modify one of the Cloudera scripts to ensure our tickets are renewable by adding +allow_renewable to the code that creates the principals:

     68 # Set the maxrenewlife for the principal, if given. There is no interface
     69 # offered by the IPA to set it, so we use KADMIN as suggested in a few IPA
     70 # related forums.
     71 #set +e
     72 KADMIN="kadmin -k -t $CMF_KEYTAB_FILE -p $CMF_PRINCIPAL -r $CMF_REALM"
     73
     74 if [ $MAX_RENEW_LIFE -gt 0 ]; then
     75   mkdir /tmp/kadmin/;
     76   klist >> /tmp/kadmin/klist.log;
     77   pwd >> /tmp/kadmin/pwd.log;
     78   whoami >> /tmp/kadmin/whoami.log;
     79   who am i >> /tmp/kadmin/who-am-i.log;
     80   echo "Running: $KADMIN -q \"modprinc -maxrenewlife \"$MAX_RENEW_LIFE sec\" $PRINCIPAL\" " >> /tmp/kadmin/kadmin-command.log;
     81   /bin/cp $CMF_KEYTAB_FILE $CMF_PRINCIPAL /tmp/kadmin/;
     82   $KADMIN -q "modprinc -maxrenewlife \"$MAX_RENEW_LIFE sec\" +allow_renewable $PRINCIPAL"
     83 fi
     84 #set -e

Save the code and redistribute it:

[root@awx01 ansible]# vi adhoc/gen_credentials_ipa.sh
[root@awx01 ansible]# ansible cm* -i infra -m copy -a 'src=adhoc/gen_credentials_ipa.sh dest=/opt/cloudera/cm/bin/gen_credentials_ipa.sh'

Once this is done, regenerate all the kerberos principals in AdministrationSecurityKerberos Credentials.

Another issue here is the Encryption Types and possibly the renewable life:

kadmin.local:  getprinc krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ
Principal: krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ
Expiration date: [never]
Last password change: [never]
Password expiration date: [never]
Maximum ticket life: 7 days 00:00:00
Maximum renewable life: 14 days 00:00:00
Last modified: Mon Feb 04 22:19:28 EST 2019 (db_creation@MWS.MDS.XYZ)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, aes256-cts-hmac-sha1-96
Key: vno 1, aes128-cts-hmac-sha1-96
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH LOCKDOWN_KEYS
Policy: [none]
kadmin.local:  modprinc -maxrenewlife 90day krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ
Principal "krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ" modified.
kadmin.local:
kadmin.local:
kadmin.local:  getprinc krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ
Principal: krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ
Expiration date: [never]
Last password change: [never]
Password expiration date: [never]
Maximum ticket life: 7 days 00:00:00
Maximum renewable life: 90 days 00:00:00
Last modified: Sat Aug 24 22:45:03 EDT 2019 (admin/admin@MWS.MDS.XYZ)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, aes256-cts-hmac-sha1-96
Key: vno 1, aes128-cts-hmac-sha1-96

MKey: vno 1
Attributes: REQUIRES_PRE_AUTH LOCKDOWN_KEYS
Policy: [none]
kadmin.local:

However the encryption types were of highest concern.  In our Cloudera Kerberos configuration, we didn't have these thereby getting:

Aug 24 22:43:38 idmipa03.mws.mds.xyz krb5kdc[12022](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.140: NEEDED_PREAUTH: hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ for krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ, Additional pre-authentication required
Aug 24 22:43:38 idmipa03.mws.mds.xyz krb5kdc[12022](info): closing down fd 11
Aug 24 22:43:38 idmipa03.mws.mds.xyz krb5kdc[12023](info): preauth (encrypted_timestamp) verify failure: Preauthentication failed
Aug 24 22:43:38 idmipa03.mws.mds.xyz krb5kdc[12023](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.140: PREAUTH_FAILED: hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ for krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ, Preauthentication failed
Aug 24 22:43:38 idmipa03.mws.mds.xyz krb5kdc[12023](info): closing down fd 11

when we tried to run:

[root@cm-r01en01 ~]# /bin/kinit -k -t /run/cloudera-scm-agent/process/749-hue-KT_RENEWER/hue.keytab -c /var/run/hue/hue_krb5_ccache hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ
kinit: Preauthentication failed while getting initial credentials
[root@cm-r01en01 ~]# 

Add the encryption types to the configuration:

Administration – Settings
     Kerberos Encryption Types
     aes256-cts-hmac-sha1-96
     aes128-cts-hmac-sha1-96

Again, regenerate the Kerberos Credentials and check the kerberos cache again:

[root@cm-r01en01 ~]# /bin/kinit -k -t /run/cloudera-scm-agent/process/904-hue-KT_RENEWER/hue.keytab -c /var/run/hue/hue_krb5_ccache hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ
[root@cm-r01en01 ~]#

Tried adjusting the kdc.conf with no luck either:

[root@idmipa04 ~]# cat /var/kerberos/krb5kdc/kdc.conf | grep default_principal_flags
  default_principal_flags = +preauth, +renewable
[root@idmipa04 ~]#

But no luck.  Ultimately, we ended up setting the flags of the /etc/krb5.conf on each CM machine instead:

[root@cm-r01en01 ~]# vi /etc/krb5.conf
[libdefaults]
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true

And the same on cm-r01en02.  That worked!

[root@cm-r01en01 ~]# klist -fe
Ticket cache: KEYRING:persistent:0:krb_ccache_Wg0x02u
Default principal: hue/cm-r01en01.mws.mds.xyz@MWS.MDS.XYZ

Valid starting       Expires              Service principal
08/25/2019 01:02:14  08/26/2019 01:02:14  krbtgt/MWS.MDS.XYZ@MWS.MDS.XYZ
        renew until 09/01/2019 01:02:14, Flags: FRIA
        Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
[root@cm-r01en01 ~]#

Cheers,
TK

kadmin: Communication failure with server while initializing kadmin interface

Getting this?

-bash-4.2$ kadmin -k -t /tmp/kadmin/cmf8392129202434993503.keytab -p cmadmin-530029b6@MWS.MDS.XYZ -r MWS.MDS.XYZ -q 'listprincs'         Authenticating as principal cmadmin-530029b6@MWS.MDS.XYZ with keytab /tmp/kadmin/cmf8392129202434993503.keytab.
kadmin: Communication failure with server while initializing kadmin interface

Ensure you have port 749 defined in your firewall config:

[root@idmipa03 ~]# cat /etc/firewalld/zones/public.xml|grep -Ei 749
  <port protocol="tcp" port="749"/>
[root@idmipa03 ~]#

Cheers,
TK


     
  Copyright © 2003 - 2025 Tom Kacperski (microdevsys.com). All rights reserved.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License

 

The IT Development and Technology Mini Vault | MicroDevSys.com
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.