Re: Call for help on improving the documentation

[Greg A. Woods]

[ On , September 22, 2000 at 00:19:29 (-0700), Russ Allbery wrote: ]
> Subject: Re: Call for help on improving the documentation
>
> A lot of applications don't really care, though, provided gethostbyname
> works reasonably well.  The other problem is that you don't want to link
> with libresolv unless you need to, since it can break otherwise working
> programs on some platforms (e.g. IRIX 5.3, from memory).

Well, gethostbyname() isn't going to work properly if you really want it
to do real DNS, at least not in the fact of real-world error conditions.

Indeed the number of applications that need real DNS support is often
not that large, but I want to make certain that people who need DNS
realise that they can't just get by with any crappy old resolver
library.

> > Similarly the functions inet_net_ntop() and inet_net_pton() will be
> > missing (they were introduced prior to BIND-4.9.5-P1 for goodness
> > sake!!).
> 
> I think you mean inet_ntop and inet_pton, the replacements for inet_ntoa
> and inet_aton that can deal with IPv6 addresses?  The only operating
> system that I've seen that has those is BSDI (and probably other BSD
> varients); Solaris didn't add them as supported functions until Solaris 8
> if I remember right, and Linux glibc 2.1 doesn't seem to have them.

No, I definitely mean inet_net_ntop() and inet_net_pton().  Inet_pton(),
for example, cannot be used to convert a CIDR-style network
specification to an internal IP number whereas inet_net_pton() can
convert a host representation (with or without the CIDR "/32" spec) to
an internal IP number.  Applications that don't want to do their own
parsers and bit-fiddling to allow a user to specify CIDR-style host and
network numbers in access lists, etc., can use inet_net_?to?() to do the
necessary conversions but not inet_pton().

> > The best solution for any application that needs DNS is to simply
> > require that the user upgrade their resolver first (eg. install
> > BIND-8.2.2-P5 or whatever's newest).
> 
> That's completely impractical in practice, at least in my opinion.  Taking
> off the programmer hat and putting on the system administrator hat for a
> moment, I would flatly refuse to install any software that required me to
> replace Solaris 2.6's resolver library, which works just fine for what we
> do with it.  I'd consider that to be unwarranted fiddling with the
> operating system.

If you want to run a news server or a mail server that interacts with
the Internet as a whole (i.e. which needs true DNS support) you really
cannot get by with any resolver library ever shipped by Sun.  They are
all more or less based on the ancient 4.8.3 code or maybe sometimes
including some fixes from the slightly newer BIND-4 releases, and they
are all very broken.  These problems are all very well documented in the
archives of the various BIND and DNS related mailing lists and
newsgroups and indeed the more recent BIND sources include descriptions
of some of these bugs, as well as of course working code that does not
suffer from these bugs.  If anyone wants to discuss these facts I'd
welcome you to e-mail me privately or to join in on one of the BIND or
DNS related forums.  Suffice it to say that for the purposes of this
forum there's a very real reason to provide advice to Autoconf users
that if they want to do DNS in their application then they'd better
watch out for broken resolver libraries and be prepared to insist on
having their application linked with something that's not quite an
antique.

With your sysadmin hat on you really shouldn't inflict Sun's bugs on
your users -- many so-called Internet problems reported by Solaris users
(both your local users as well as perhaps the remote users trying to
make heads or tails out of your server's behaviour) are in fact really
due to bugs in Sun's libresolv.  Been there, done that, got the bruises
to show.  Even Solaris-8 is basically unusable out-of-the-box for a
serious e-mail application, at least for anyone not willing to tolerate
unexpected, unpredictable, incorrect, behaviour.

With your programmer's hat on you'd be much better off forcing people to
upgrade their nameserver and and its resolver libraries so that your
application won't be fingered for having those bugs.  You'll also be
assisting the aformentioned administrator!

> Anyway, apart from philosophy on that, the underlying theory of autoconf
> appears to be to provide as much facilities for working around broken
> systems as possible.

Well, yes, to the extent where it should be able to detect such broken
systems, and/or at least know what they are.  It is not autoconf's job
to actually provide work-arounds -- that's left to the programmer.
I.e. how you (as the programmer) deal with the knowledge that the
resolver library the installer has provided for your build (be it
explicitly provided, or simply found as the default on the system), is
up to you.  If you are writing an application that needs to do real DNS
with the real world you can ship your own copy of a resolver library
with your application to work around known bugs in the system-supplied
version, or simply have autoconf bail out with an error that says
something to the effect of "Get Real!  You don't really expect me to use
that broken old piece of crap, do you?"

With the resolver functions in particular there are not really any ways
to concoct a test scenario within the confines of autoconf.  You have to
rely on knowing where the bugs exist based on the system type, or in
detecting known buggy versions by looking for indicators such as the
lack of hstrerror().

> Ah, okay; INN has that for 4.2BSD portability, then (along with the mem*
> stuff).  At some point, I'm likely to just drop portability to 4.2BSD (in
> practice, I'm pretty sure we already have, given that we now require mmap
> and I doubt 4.2BSD had it).

Hmmm... yes, I've been wondering just how wise it is to keep autoconf in
particular ready to deal with V7, 4.2BSD, SysVr2.2, and other true
antiques.....  Certainly I could fire up a PDP-11 or a VAX (or emulator
if I'm in a rush) and boot any one of Sys-III, V7, 32/V, or 4.2 and try
out a modern Internet application, but I'd never expect to be able to
use such a system for a production service.  I haven't even fired up my
SysVr3.2, or even my SunOS-4 systems, for the last few years to see if
my programs still build and work on them.  Such portability is truly
just an academic excercise in this day and age, especially when any VAX
capable of running fast enough to even be usable any more is capable of
running a modern OS.  Perhaps it'll keep our skills sharp enough for the
next generation of systems, but I'd rather bet that it'll simply cause
more confusion than insight.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>      <robohack!woods>
Planix, Inc. <address@hidden>; Secrets of the Weird <address@hidden>