On an empty atomic host, there is no reasonable way of manually performing DNS lookups. This makes it very hard to debug DNS-related issues, and so it'd be great if bind-utils (dig) or similar could be included in the base image.
This cannot be solved with a container, because if DNS is broken then docker pull won't work.
Other than debugging, is there a need for this? We're going to wind up with a very bloated image if we keep stuffing things in for debugging.
I wonder if we shouldn't have a separate Atomic image with debug tools or something so we can keep a smaller image for using Atomic as intended.
I think this is something that is crucial to add for the simple reason that if dns is broken we can't find the registry to download a tools image. I have found myself in this position several times and "using IP addresses doesn't suffice when you are trying to use a complicated tool that references other names, etc.. when trying to connect".
This absolutely has to go in, IMHO.
How about glibc's getent? E.g.
-bash-4.3# getent ahostsv4 google.com 216.58.219.206 STREAM google.com 216.58.219.206 DGRAM 216.58.219.206 RAW
-bash-4.3# getent ahostsv6 google.com 2607:f8b0:4006:80e::200e STREAM google.com 2607:f8b0:4006:80e::200e DGRAM 2607:f8b0:4006:80e::200e RAW
Just as a data point, rhelah / centos atomic does have bind-utils. But, if we can be slimmer while maintaining functionality, as w/ the getent example above, great.
I'd rather have the real tools. getent doesn't let me specify an alternative DNS host does it? Is it a host problem, is it a dns host problem, is it a networking problem?
People are used to having those tools.. I'd say for something so fundamental (dns) we should have a way to debug that easily, especially if a sysadmin needs to debug a dns problem in a short amount of time.
Unfortunately, bind-utils has a bunch of deps, including as currently packaged GeoIP and the GeoIP database.
Replying to [comment:6 mattdm]:
Could we include busybox then? At least busybox has nslookup. and we could create /bin/nslookup-busybox symlink or something like that if we wanted to make it easy for users to discover.
Replying to [comment:7 dustymabe]:
Replying to [comment:6 mattdm]: Unfortunately, bind-utils has a bunch of deps, including as currently packaged GeoIP and the GeoIP database. Could we include busybox then? At least busybox has nslookup. and we could create /bin/nslookup-busybox symlink or something like that if we wanted to make it easy for users to discover.
Heh, yeah, I was just going through the same thought process. In fact, I wonder if we should include busybox and then remove as much as we can of other utilties that busybox could reasonably cover.
Came here to say what mattdm said. I think that would be awesome if we could adopt busybox here and get rid of a bunch of other stuff.
Nothing says "this is an appliance" like busybox! :)
Replying to [comment:3 jlebon]:
How about glibc's getent?
Yes, I am curious what use case isn't covered by this.
On the other hand, there unfortunately isn't an explicit rationale for the inclusion of bind-utils into RHEL AH, but mattdm's comment on the GeoIP dependency is a bit of an issue for doing the same in Fedora.
My inclination here is that a lot of this would be best covered by a stackoverflow site that people in the group help maintain.
"How do I debug DNS issues" -> getent
etc
One other thing to bear in mind - down the line DNSSEC is coming, and the local resolver had better have useful debug tools built in. I haven't looked at unbound or systemd-resolved in anger, but I hear at least the latter doesn't have debug info: http://lists.freedesktop.org/archives/systemd-devel/2014-October/024133.html
(mattdm ticket:145#comment:8) Unfortunately, bind-utils has a bunch of deps, including as currently packaged GeoIP and the GeoIP database.
I did a quick F23 compose today to check, we only add 4 packages for bind-utils. GeoIP is already included in the latest tree. For this particular add, I don't see a lot of bloat.
Having an alternative like busybox as a way to first try to satisfy a new tool request would be interesting. Especially since there's a decent reduction in overhead to test and no net add.
(jlebon) How about glibc's getent? (walters ticket:145#comment:8) Yes, I am curious what use case isn't covered by this.
I think getent is just unfamiliar to most folks to use and understand. You can change the dns host being queried by changing /etc/resolv.conf, but how many folks know that?
getent
Pointing to Google over having one of several common tools needs a pretty strong argument. Especially if we can get busybox in to cover things as a first resort, with the addition of the official packages as a fall back if there are additional dependencies or unexpected behavior.
The problem would be adding the symlinks for busybox to an expected place for users. There was some talk on IRC on how to do this, but it's just as important to have nslookup in the path with a standard invocation if we go the busybox route, or busybox nslookup is as much of a "RTFSE" issue as explaining getent.
nslookup
busybox nslookup
Closing this ticket as part of trac clean up process. If you want to reopen, please reopen it after we move to pagure.io as atomic-wg.
Login to comment on this ticket.