> If it doesn’t have all the bells and whistles, then it shouldn’t be on port 53 by default.
Sure, I’ll change the default port to not use 53 and document it.
> *how* is it getting launched on a privileged port? It sounds like the expectation is to run “command” as root.   *ALL* of the previous daemons in Hadoop that needed a privileged port used jsvc.  Why isn’t this one? These questions matter from a security standpoint.  
Yes, it is running as “root” to be able to use the privileged port. The DNS server is not yet integrated with the hadoop script.

> Check the output.  It’s pretty obviously borked:
Thanks for pointing out. Missed this when rebasing onto trunk.

> On Sep 5, 2017, at 3:11 PM, Allen Wittenauer <[EMAIL PROTECTED]> wrote:
>
>
>> On Sep 5, 2017, at 2:53 PM, Jian He <[EMAIL PROTECTED]> wrote:
>>
>>> Based on the documentation, this doesn’t appear to be a fully function DNS server as an admin would expect (e.g., BIND, Knot, whatever).  Where’s forwarding? How do I setup notify? Are secondaries even supported? etc, etc.
>>
>> It seems like this is a rehash of some of the discussion you and others had on the JIRA. The DNS here is a thin layer backed by service registry. My understanding from the JIRA is that there are no claims that this is already a DNS with all the bells and whistles - its goal is mainly to expose dynamic services running on YARN as end-points. Clearly, this is an optional daemon, if the provided feature set is deemed insufficient, an alternative solution can be plugged in by specific admins because the DNS piece is completely decoupled from the rest of native-services.
>
> If it doesn’t have all the bells and whistles, then it shouldn’t be on port 53 by default. It should also be documented that one *can’t* do these things.  If the standard config is likely to be a “real” server on port 53 either acting as a secondary to the YARN one or at least able to forward queries to it, then these need to get documented.  As it stands, operations folks are going to be taken completely by surprise by some relatively random process sitting on a very well established port.
>
>>> In fact:  was this even tested on port 53? How does this get launched such that it even has access to open port 53?  I don’t see any calls to use the secure daemon code in the shell scripts. Is there any jsvc voodoo or is it just “run X as root”?
>>
>> Yes, we have tested this DNS server on port 53 on a cluster by running the DNS server as root user. The port is clearly configurable, so the admin has two options. Run as root + port 53. Run as non-root + non-privileged port. We tested and left it as port 53 to keep it on a standard DNS port. It is already documented as such though I can see that part can be improved a little.
>
> *how* is it getting launched on a privileged port? It sounds like the expectation is to run “command” as root.   *ALL* of the previous daemons in Hadoop that needed a privileged port used jsvc.  Why isn’t this one? These questions matter from a security standpoint.  
>
>>> 4) Post-merge, yarn usage information is broken.  This is especially bad since it doesn’t appear that YarnCommands was ever updated to include the new sub-commands.
>>
>> The “yarn” usage command is working for me. what do you mean ?
>
> Check the output.  It’s pretty obviously borked:
>
> ===snip====
>
>    Daemon Commands:
>
> nodemanager          run a nodemanager on each worker
> proxyserver          run the web app proxy server
> resourcemanager      run the ResourceManager
> router               run the Router daemon
> timelineserver       run the timeline server
>
>    Run a service Commands:
>
> service              run a service
>
>    Run yarn-native-service rest server Commands:
>
> apiserver            run yarn-native-service rest server
>
>
> ===snip===
>
>> Yeah, looks like some previous features also forgot to update YarnCommands.md for the new sub commands
>
> Likely.  But I was actually interested in playing with this one to compare it to the competition.  [Lucky you. ;) ]  But with pretty much zero documentation….
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB