> 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 <a...@effectivemachines.com> > wrote: > > >> On Sep 5, 2017, at 2:53 PM, Jian He <j...@hortonworks.com> 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…. > >
