hdfs,yarn,hive etc are system users, they will not have any passwords by default, however you can su from root. If you really want set passwords anyway then $ passwd hdfs command will prompt you to set a new password but i don't see a reason why anyone want to do that for system users.  ... View more

You may have to write one using Ambari API  http://<ambari-server-host>:<port>/api/v1/<resource-path>   Ref: https://github.com/apache/ambari/blob/trunk/ambari-server/docs/api/v1/index.md   Can use just plain CURL or Python to dump JSON and further convert to whichever format you like.  ... View more

tier1.sources.source1.zookeeperConnect is deprecated, use tier1.sources.kafkasource1.kafka.bootstrap.servers = bda03:9092, bda04:9092,bda05:9092. ... View more

You can use PURGE option to delete data file as well along with partition mentadata but it works only in INTERNAL/MANAGED tables ALTER TABLE table_name DROP [IF EXISTS] PARTITION partition_spec PURGE;   External Tables have a two step process to alterr table drop partition + removing file ALTER TABLE table_name DROP [IF EXISTS] PARTITION partition_spec; hadoop fs -rm -r <partition file path> ... View more

Change the download path when you go through the initial setup of CDH where it asks to specify the parcel repository ... View more

There are different ways you can avoid this problem depending on your data blocks.. 1) if you have a data under-replicated it should just automatically replicate the blocks to other data nodes to match the replication factor 2) if it is not replicating on your own run a balancer 3) you can also set replication on a specific file which is under replicated 4) if it is just a temp file which is created while running the job when your speculative execution tasks are high, make the speculative execution tasks nearly match the replication factor so that it wouldn't complain about the temp files after the job run. ... View more

you trying to write and read the file at the same time ? ... View more

the /etc/hadoop/conf is the default path that hadoop uses /run/cloudera....... is the one that cloudera services export the confs and run from there, either way it works, if you make any changes on CM it gets effective in /run/cloudera.... and when you deploy client configs it gets reflected in /etc/hadoop.... Its just the CM way of doing/running things, no big difference... If you want to add a property to the cluster configuration there is an option in cloudera manager which allows you to add new configurations, I am not sure where can we find it but there is a way to do it as far as i know... Thanks ... View more

AFter you apply the changes in CM you will need to re-deploy the client configs to get those changes reflected on the client machine... ... View more