pool and restrictions

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> > Fair enough.  I have an idea for a simple way to implement this.  But I
> > can't find where the hole-poking is actually being done - it's apparently
> > not via a hack_restrict() call, which is what I'd have expected.  Can you
> > give me a file and line number? 
> 
> ntp_proto.c, line 2480, in dns_take_pool
>         restrict_mask = restrictions(&peer->srcadr);
>         /* FIXME-DNS: RES_FLAGS includes RES_DONTSERVE?? */
>         if (RES_FLAGS & restrict_mask) {
>                 msyslog(LOG_INFO, "Pool poking hole in restrictions for: %s",
>                                 socktoa(&peer->srcadr));
>                 restrict_source(&peer->srcadr, false,
>                                 current_time + POOL_SOLICIT_WINDOW + 1);
>         }

OK.  I think your hole-filling might already be done in the restrict_source()
call here:

/*
 * unpeer - remove peer structure from hash table and free structure
 */
void
unpeer(
	struct peer *peer
	)
{
	mprintf_event(PEVNT_DEMOBIL, peer, "assoc %u", peer->associd);
	restrict_source(&peer->srcadr, true, 0);
	set_peerdstadr(peer, NULL);
	peer_demobilizations++;
	peer_associations--;
	if (FLAG_PREEMPT & peer->flags)
		peer_preempt--;
#ifdef REFCLOCK
	/*
	 * If this peer is actually a clock, shut it down first
	 */
	if (FLAG_REFCLOCK & peer->flags)
		refclock_unpeer(peer);
#endif

	free_peer(peer);
}

> >> Maybe we should add another flag to disable poking holes.
> >> Maybe it's an enhancement rather than bug fix, but this would
> >> be the time to do it.
> > I'm generally opposed to adding more interface knobs.  The configuration
> > language is tricky enough as it is.  Why do you think we might need one? 
> 
> With the current setup, restrict is essentially ignored for pool hosts.  
> There is no way to say "I want to use the pool, but skip hosts at 
> a.b.c.d/16".  It will poke a hole in that restriction.  You might want to do 
> that because your routing to there is crappy so you get crappy time.  Or 
> maybe they are known bad guys and the pool operators are slow to respond or 
> don't think they are bad enough to kick out or ...
> 
> I generally agree with your more knobs comment.  This might be filling in a 
> hole and thus make things cleaner overall rather than more complicated.
> 
> If we don't fix this, we should at least make sure the documentation is clear.

I'll take a doc patch to that effect; also please add this RFE to devel/TODO.

You make a good case, but I want to get our decks cleared of tracker issues
before we start in on stuff like this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.