[
https://issues.apache.org/jira/browse/HADOOP-785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525473
]
Doug Cutting commented on HADOOP-785:
-------------------------------------
> The only thing that you can't do is put secret keys into the server's
> hadoop-site.xml [...]
Where do we expect to keep secret keys? In the Configuration? If so, this
could be a serious problem. For jobs, the JobConf is the obvious place to put
keys. I don't know that the tasktracker will need its own keys but let's
assume it does. JobConf's are written by JobClient to mapred.system.dir. We
could make that directory world-writable but readable by only the jobtracker,
so users could securely put their keys in a JobConf. The users' keys would
normally overwrite the servers keys when the configurations are merged, but
that's not 100% reliable, if, e.g., the client somehow manages to include no
keys in a JobConf then it would see the servers keys, which would be bad.
> Divide the server and client configurations
> -------------------------------------------
>
> Key: HADOOP-785
> URL: https://issues.apache.org/jira/browse/HADOOP-785
> Project: Hadoop
> Issue Type: Improvement
> Components: conf
> Affects Versions: 0.9.0
> Reporter: Owen O'Malley
> Assignee: Arun C Murthy
> Fix For: 0.15.0
>
> Attachments: HADOOP-785_1_20070903.patch, HADOOP-785_2_20070906.patch
>
>
> The configuration system is easy to misconfigure and I think we need to
> strongly divide the server from client configs.
> An example of the problem was a configuration where the task tracker has a
> hadoop-site.xml that set mapred.reduce.tasks to 1. Therefore, the job tracker
> had the right number of reduces, but the map task thought there was a single
> reduce. This lead to a hard to find diagnose failure.
> Therefore, I propose separating out the configuration types as:
> class Configuration;
> // reads site-default.xml, hadoop-default.xml
> class ServerConf extends Configuration;
> // reads hadoop-server.xml, $super
> class DfsServerConf extends ServerConf;
> // reads dfs-server.xml, $super
> class MapRedServerConf extends ServerConf;
> // reads mapred-server.xml, $super
> class ClientConf extends Configuration;
> // reads hadoop-client.xml, $super
> class JobConf extends ClientConf;
> // reads job.xml, $super
> Note in particular, that nothing corresponds to hadoop-site.xml, which
> overrides both client and server configs. Furthermore, the properties from
> the *-default.xml files should never be saved into the job.xml.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.