[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [leafnode-list] fqdn validation

Matthias Andree wrote:
> Jonathan Larmour wrote on 2002-04-10:
> > validatefqdn() checks that the fqdn isn't localhost. However fqdn is set by
> > miscutil.c:whoami() which includes:
> >
> >     if (!gethostname(fqdn, 255) && (he = gethostbyname(fqdn)) != NULL) {
> >         strncpy(fqdn, he->h_name, 255);
> >         if (strchr(fqdn, '.') == NULL) {
> >          [ use a DNS alias ]
> >
> > The thing is that although I set up a valid fqdn (foo.bar.org) with a
> > sensible IP addr, my system has its /etc/hosts set up such that foo.bar.org
> > is address, i.e.:
> >
> >             localhost.localdomain localhost foo.bar.org foo
> >
> > This is to cut out overhead for times where the machine connects to itself,
> > and is in fact how Red Hat Linux sets itself up by default.
> <shrug> killing 25 µs ping time off a Duron/700. Wonder if that's
> worthwhile.  And will in fact kill protocols that encode the own IP as
> payload, because the IP lookup will yield rather than the
> actual IP.  What a brilliant idea. OK, we're not here to discuss
> distro madness.

Well I think one of the other reasons is to ensure better local connection
persistence when using DHCP and/or dialup connections.

Although looking at it, it would seem better to put the other entries on
their own line, i.e.             localhost.localdomain localhost             foo.bar.org foo

> > The problem is that the above code results in he->h_name being set to
> > localhost.localdomain since that is the canonical name (and for
> > that's correct). This then causes validatefqdn() to complain.
> If a lookup (to qualify the domain) for "foo" yields
> localhost.localdomain, that's a hosed setup. Why do Red Hat set up
> localhost.localdomain if they have a real domain? unqualified
> "localhost", OK, but a qualified "localhost" is heading for trouble.

localhost.localdomain is the FQDN of localhost. And the convention is that
FQDNs are listed as the canonical names where possible.

> > I think the correct answer is simply to delete the strncpy(). Setting fqdn
> Is that portable? How about really old libcs, say, SunOS 4.1.3?

Eh? Removing a line non-portable?
> > to the canonical name won't really achieve much since using an alias should
> > have the same effect anyway.
> *shrug* More verbosely, please.

No really, it's not at all clear to me why the validation is done this way
such that the fqdn is substituted *back* in. The user has given a name and
that name, if it works, is what appears in the banner and posts etc.
Certainly the user given name shouldn't be localhost, but the fact the
address of that name  _happens_ to map to shouldn't be a problem.

Choosing any one of the aliases on the basis of it being the textually
longest really doesn't seem right though. e.g. our news machine here in the
office is called "invincible.cambridge.redhat.com" but its alias of
news.cambridge.redhat.com is what we want to appear in all the banners,
RFC822 Path, etc.
> > If people agree, it would be nice to have this in any eventual 1.9.22. I
> > don't see any checking any longer in the 2.0b series, so presumably it
> > wouldn't have this problem.
> FQDN validation will not be dropped.
> However, if the logic to retrieve the actual host name can be improved,
> so be it. The length-logic as in 1.9.21 is not too bright, admittedly.
> Rest assured that leafnode 2.0.x will do domain validation as well.
> Please try the patch below and report back if that works for you. If you
> want debug information in your syslog, just try something like:

It doesn't since the strlen("localhost.localdomain") happens to be longer
than the machine in question's name. It could have been the other way round
of course.

All I'm trying to do is let leafnode work "out of the box" on more
machines. *My* problem is fixed :-).

Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list