[leafnode-list] Re: leafnode2 hostname problems

[Matthias Andree <matthias.andree@xxxxxx>]

Martin <virenfang@xxxxxxxx> writes:

> Please let me drop a note to xinetd:
>
> On Fri, Jun 09, 2006 at 12:47:28AM +0200, Matthias Andree wrote:
>> Troy Piggins <troy@xxxxxxxxx> writes:
>> 
>> > Hmm.  Applied the patch.  Recompiled, make installed, restarted
>> > xinetd:
>> 
>> No need to restart xinetd. It will start a new leafnode process (with
>> new process and perhaps new configuration) for each and every new
>> connection.
>
> Are you sure?
>
> man xinetd.conf:
>
> |flags            Any combination of the following flags may be used:
> [...]
> |     REUSE       The  REUSE flag is deprecated.  All services now
> |                 implicitly use the REUSE flag.
>
> I do not know whether I understand this right (then an open pipe from
> xinetd to leafnode will be kept alive for some time and be reused when
> there's a new request for nntp).

No. It just runs setsockopt with SO_REUSEADDR if I recall correctly.  It
definitely doesn't cause xinetd to keep connections open. That's
something xinetd has no control over (at least not for stream (TCP)
sockets anyways), because client and server negotiate the end of the
connection at their discretion. If the client (newsreader) sends "QUIT",
leafnode quits, there's nothing xinetd could do about it.

For every new connection, xinetd starts a new leafnode process.

> I do not know whether you insure restarting leafnode with every new
> request either.

Not for every new request, but for every new connection. That's the way
super-servers such as inetd, xinetd, ipsvd or the proprietary ucspi-tcp
work.

> (In this case leafnode would exit() or something closing the pipe to
> xinetd this way - I'm hoping that this is possible at all.)

It is possible, and leafnode does that.

>> Does leafnode still work if you comment out its
>> hostname=... configuration line? It should.
>
> You can *really* play around with xinetd having a lot of fun with
> bindings.

And it can get quite annoying in earlier xinetd versions than Troy's.

> If I remember correctly, xinetd
>
> |defaults
> |{
> |        only_from      = localhost
> |        bind           = 127.0.0.1
> [...]
> |}
>
> (excerpt from /etc/xinetd.conf)
>
> So only connections from localhost are allowed, and services only listen
> on 127.0.0.1. (Please don't ask for the difference. ;-) )

Quite interesting that you don't claim to know the difference but ask
/me/ if I am sure about xinetd behavior.

Anyways, the latter implies the former. If a service listens on a
particular address, then that particular address must be the destination
address for the connection, and usually routing tables do the rest;
since for instance 127.0.0.1 is routed through the loopback device, it
only works on the same computer because loopback packets never travel
over Ethernet.  only_from is another means of access control, but xinetd
usually ships with libwrap compiled in, and so the same set of
hosts.allow instructions can be used for traditional inetd with tcpd,
for modern inetd with libwrap and for xinetd with libwrap.

> By the way: Long time ago I had a similar problem, having a line like 
> |192.168.0.1  armadillo  armadillo.piggo.dyndns.org
>
> This was solved as described by you:
> |192.168.0.1  armadillo.piggo.dyndns.org  armadillo

I think I mentioned this earlier.

-- 
Matthias Andree
-- 
_______________________________________________
leafnode-list mailing list
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
https://www.dt.e-technik.uni-dortmund.de/mailman/listinfo/leafnode-list
http://leafnode.sourceforge.net/