Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Override manual config changes using cloudera manager

avatar
Master Collaborator

Hi Community,

Suppose that i changed one of the values in the node hdfs-site.xml manually, will cloudera manager override this config?

example : in /etc/hadoop/conf i want to change the dfs.nameservices in  hdfs-site.xml manually and i want to how cloudera manager can override this.

 

*** I don't want to make such a change but i want to know if cloudera manager can override this.

1 ACCEPTED SOLUTION

avatar
Master Mentor

@Fawze 

AFAIK  all changes made manually by editing the files using VI or nano is not persisted in the CM or Ambari database which means CDH or HDP is even not aware of that change so at startup it will get the values of the configuration from the persisted database.

When you use CM/Ambari to change values the save button triggers an update in the underlying CM/Ambari tables that said it's NOT advisable to manually edit config files.

Happy hadooping  

View solution in original post

4 REPLIES 4

avatar
Master Mentor

@Fawze 

AFAIK  all changes made manually by editing the files using VI or nano is not persisted in the CM or Ambari database which means CDH or HDP is even not aware of that change so at startup it will get the values of the configuration from the persisted database.

When you use CM/Ambari to change values the save button triggers an update in the underlying CM/Ambari tables that said it's NOT advisable to manually edit config files.

Happy hadooping  

avatar
Master Collaborator

Thanks @Shelton for your response, just to make sure i understand this as it should be.

 

The change that done manual has no meaning? suppose i change the config using ACL to false in one of the hadoop conf files in one node and in cloudera manager it's true, will the node that i made the change will take the value that i edited or the value in the cloudera? what i got from your answer that restarting the cloudera-scm agent or the the service may override the manual change i did?

 

how i can trigger the change that i did in the node using vim or nano to take the value from cloudera manager?

avatar
Master Mentor

@Fawze 

In a Hadoop distribution ACLs are disabled by default. When ACLs are disabled, the NameNode rejects all attempts to set an ACL you will need to enable that manually in CM/Ambari.

 

Enabling HDFS ACLs Using Cloudera Manager

  1. Go to the Cloudera Manager Admin Console and navigate to the HDFS service
  2. Click the Configuration tab.
  3. Select Scope > Service_name (Service-Wide)
  4. Select Category > Security
  5. Locate the Enable Access Control Lists property and select its checkbox to enable HDFS ACLs. [Enter a Reason for change, and then]
  6. Click Save Changes to commit the changes.

The above sequence sets the dfs.namenode.acls.enabled property to true in the NameNode's hdfs-site.xml. This is a cluster-wide operation so only after doing the above you can run the setfacl or getfacl commands against an HDFS file etc

<property>
<name>dfs.namenode.acls.enabled</name>
<value>true</value>
</property>

The hdfs-site.xml is distributed by CM, when you make a change you are usually warned that there is a stale configuration and you are asked to restart the service this triggers the distribution of the new hdfs-site.xml to all nodes in the cluster and that's precisely the reason to use CM rather than manually editing.
Happy hadooping

avatar
Master Collaborator

@Shelton Yes, i understand and know how to change this through CM, my question is that i changed it manually in one of the nodes this setting, will the node that this config locally where i changed it or will take what is the value in CM? what i need to do if i want to revert the manual change through CM and not reverting the change manually from the node.

 

I want to proof that manual changes has no impact and it can be overriden through CM.

i provided ACL only as an example but it can be any other config