@Manoj690  It's always a good idea to share the HDP and Zk version plus the zk logs in /var/log/* having said that can you share your zoo.cfg ? If you really need enable all four letter word commands by default, you can use the asterisk option so you don't have to include every command one by one in the list.See below 4lw.commands.whitelist=* As you have not shared your logs that's a starting point, then restart your zookeeper and let me know! ... View more

@Seaport  As the permission is with the zeppelin user  [other] you will need to do that at a user level, remember fine-grained security ONLY give what is necessary !! $ hdfs dfs -getfacl /warehouse/tablespace/managed/hive # file: /warehouse/tablespace/managed/hive # owner: hive # group: hadoop user::rwx group::--- other::--- default:user::rwx default:user:hive:rwx default:group::--- default:mask::rwx default:other::--- The command below will set [ r-x } bits to  the correct ACL you can change to rwx if you wish hdfs dfs -setfacl -R -m user:zeppelin:r-x /warehouse/tablespace/managed/hive   Thereafter the zeppelin user can    [zeppelin~]$ hdfs dfs -ls /warehouse/tablespace/managed/hive Found 3 items drwxrwx---+ - hive hadoop 0 2018-12-12 23:42 /warehouse/tablespace/managed/hive/information_schema.db drwxrwx---+ - hive hadoop 0 2018-12-12 23:41 /warehouse/tablespace/managed/hive/sys.db drwxrwx---+ - hive hadoop 0 2020-01-15 00:20 /warehouse/tablespace/managed/hive/zepp.db The earlier error is gone  ls: Permission denied: user=zeppelin, access=READ_EXECUTE, inode="/warehouse/tablespace/managed/hive":hive:hadoop:drwx------   Happy hadooping   ... View more

@mike_bronson7    When your cluster is in HA it uses a namespace that acts as a load balancer to facilitate the switch from active to standby and vice versa. The dfs-site-xml holds these values  filter using  dfs.nameservices  the nameservice-id  should be your namespace or in HA look for dfs.ha.namenodes.[nameservice ID]   dfs.ha.namenodes.[nameservice ID] e.g dfs.ha.namenodes.mycluster   And that's the value to set  eg    hdfs://mycluster_namespace/user/ams/hbase   The refresh the stale configs , now HBase should sending the metrics  to that directory  HTH   ... View more

@Niruu  Here is a link changing ambari hostnames that should help you. I have used it successfully before but there are 2 hidden undocumented caveats, you should manually change the hostname in the ambari.properties there should be 2 or 3 properties to match the new VM hostname and also run some SQL like alter in the ambari, ranger, oozi, hive  databases you have to do this for all the fore mentioned components. The contents of your host_names_changes.json should look like below make sure you have the correct cluster name, you will be prompted if you have already backed up your database etc in my case I usually  just accept , with a VM you can easily create another snapshot and you are good to go. You must have completely stopped ambari and the agents  host_names_changes.json   { "cluster1" : { "ambari01.example.com" : "ambari02.example.com" } }     The command should look like this  #  ambari-server update-host-names  + host_names_changes.json   # ambari-server update-host-names host_names_changes.json   After completion, you should see successful Note : Remember to update the ambari-agent.ini to point to the new ambari02.example.com   If you use the above document you could stop on number 8 you don't need to format you Zk For ambari database I am assuming you are using MariaDB or Mysql   mysql -u <ambari_user> -p<ambari_user_password> GRANT ALL PRIVILEGES ON *.* TO 'ambari'@'<new_FQDN_new_VM>'; GRANT ALL PRIVILEGES ON *.* TO 'ambari'@'<new_FQDN_new_VM>' IDENTIFIED BY '<ambari_user_password>';   Hive to that for all the rest   mysql -u <hive_user> -p<hive_user_password> GRANT ALL PRIVILEGES ON *.* TO 'hive'@'<new_FQDN_new_VM>'; GRANT ALL PRIVILEGES ON *.* TO 'hive'@'<new_FQDN_new_VM>' IDENTIFIED BY '<hive_user_password>'; Hope that helps  Happy hadooping     ... View more

@asmarz  On the edgenode Just to validate your situation I have spun up single node cluster Tokyo IP 192.168.0.67 and installed an edge node Busia IP 192.168.0.66 I will demonstrate the spark client setup on the edge node and evoke the spark-shell First I have to configure the passwordless ssh below my edge node   Passwordless setup [root@busia ~]# mkdir .ssh [root@busia ~]# chmod 600 .ssh/ [root@busia ~]# cd .ssh [root@busia .ssh]# ll total 0   Networking not setup The master is unreachable from the edge node [root@busia .ssh]# ping 198.168.0.67 PING 198.168.0.67 (198.168.0.67) 56(84) bytes of data. From 198.168.0.67 icmp_seq=1 Destination Host Unreachable From 198.168.0.67 icmp_seq=3 Destination Host Unreachable   On the master The master has a single node HDP 3.1.0 cluster, I will deploy the clients to the edge node from here [root@tokyo ~]# cd .ssh/ [root@tokyo .ssh]# ll total 16 -rw------- 1 root root 396 Jan 4 2019 authorized_keys -rw------- 1 root root 1675 Jan 4 2019 id_rsa -rw-r--r-- 1 root root 396 Jan 4 2019 id_rsa.pub -rw-r--r-- 1 root root 185 Jan 4 2019 known_hosts   Networking not setup The edge node is still unreachable from the master Tokyo   [root@tokyo .ssh]# ping 198.168.0.66 PING 198.168.0.66 (198.168.0.66) 56(84) bytes of data. From 198.168.0.66 icmp_seq=1 Destination Host Unreachable From 198.168.0.66 icmp_seq=2 Destination Host Unreachable   Copied the id-ira.pub key to the edgenode [root@tokyo ~]# cat .ssh/id_rsa.pub | ssh root@192.168.0.215 'cat >> .ssh/authorized_keys' The authenticity of host '192.168.0.215 (192.168.0.215)' can't be established. ECDSA key fingerprint is SHA256:ZhnKxkn+R3qvc+aF+Xl5S4Yp45B60mPIaPpu4f65bAM. ECDSA key fingerprint is MD5:73:b3:5a:b4:e7:06:eb:50:6b:8a:1f:0f:d1:07:55:cf. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.215' (ECDSA) to the list of known hosts. root@192.168.0.215's password:   Validation the passwordless ssh works [root@tokyo ~]# ssh root@192.168.0.215 Last login: Fri Jan 10 22:36:01 2020 from 192.168.0.178 [root@busia ~]# hostname -f busia.xxxxxx.xxx xxxxxx Single node Cluster  [root@tokyo ~]# useradd asmarz [root@tokyo ~]# su - asmarz   On the master as user asmarz  I can access the spark-shell and execute any spark code   Add the edge node to the cluster   Install the clients on the edge node   On the master as user asmarz  I have access to the spark-shell Installed Client components on the edge-node can be seen in the CLI     I chose to install all the clients  on the edge node just to demo as I have already install the hive client on the edge node  without any special setup I can now launch the hive HQL  on the master Tokyo from the edge node  After installing the spark client on the edge node I can now also launch the spark-shell  from the edge node and run any spark code, so this demonstrates that you can create any user on the edge node and he /she can rive Hive  HQL, SPARK SQL  or PIG script. You will notice I didn't update the  HDFS , YARN, MAPRED,HIVE  configurations it was automatically done by Ambari during the installation it copied over to the edge node the correct conf files !! The asmarz user from the edge node can also acess HDFS   Now as user asmarz  I have launched a spark-submit job  from the edge node  The launch is successful on the master Tokyo  see Resource Manager URL, that can be confirmed  in the RM UI This walkthrough validates that any user on the edge node can launch a job in the cluster this poses a security problem in production hence my earlier hint of Kerberos. Having said that  you will realize I didn't  do any special configuration  after the client installation because Ambari distributes the correct configuration of all the component  and it does that for every installation of a new component that's the reason  Ambari is a management tool If this walkthrough answers your question, please do accept the answer and close the thread. Happy hadooping  ... View more