Re: your mail

>There seems to be a number of issues with /etc/{daily,weekly,monthly}.
>
>misc/14825: asks for all the scripts to be unified, so that (for
>example) setting rebuild_locatedb=YES in daily.conf would cause
>the locatedb to be rebuild daily, rather than weekly. Greg Woods
>then suggested that our whole framework should be replaced by
>something like FreeBSD's periodic(8).

that's being looked at, but isn't a terribly pressing task, i'm
afraid.

>misc/11011: points out that when bringing a laptop up from several
>days or more of bieng suspended, the daily/weekly scripts immediately
>kick in and start several very battery-expensive operations (i.e.
>find / ...). John Hawkinson replied, suggesting that the multiple
>find / operations could probably be eliminated, and mentioned some
>other problems with daily/weekly scripts on laptops.

ooh!  we already fixed that.  months ago, too.  no idea there was a
pr.  i'll close it.

>Several other open PR's ask for tweaks or extra options. See: 
>bin/17029, bin/20272, bin/22148, bin/22230, misc/7716, misc/11046
>misc/17306, misc/18628.

okay, let's see...

17029	interesting idea
20272	again, interesting idea
22148	hmm...this is only tangentially related

Re: periodic(8) etc.

On Wed, Oct 01, 2003 at 12:51:15AM -0400, Andrew Brown wrote:
> >There seems to be a number of issues with /etc/{daily,weekly,monthly}.
> >
> >misc/14825: asks for all the scripts to be unified, so that (for
> >example) setting rebuild_locatedb=YES in daily.conf would cause
> >the locatedb to be rebuild daily, rather than weekly. Greg Woods
> >then suggested that our whole framework should be replaced by
> >something like FreeBSD's periodic(8).
> 
> that's being looked at, but isn't a terribly pressing task, i'm
> afraid.

...which is why I'm volunteering to do it 

> >misc/11011: points out that when bringing a laptop up from several
> >days or more of bieng suspended, the daily/weekly scripts immediately
> >kick in and start several very battery-expensive operations (i.e.
> >find / ...). John Hawkinson replied, suggesting that the multiple
> >find / operations could probably be eliminated, and mentioned some
> >other problems with daily/weekly scripts on laptops.
> 
> ooh!  we already fixed that.  months ago, too.  no idea there was a
> pr.  i'll close it.
> [...]  
> okay, let's see...
> 
> 17029	interesting idea
> 20272	again, interesting idea
> 22148	hmm...this is only tangentially related
> 22230	ah, good point

/etc/rc.d/ scripts that depend on multiple rc configs

Hi,

today I investigated in an issue that has bothered me for some time now. 
I'm using both ipfilter and ipnat. My /etc/rc.conf contains nothing 
besides rc_configured=YES and hostname="[...]". All my rc configs live 
separately in /etc/rc.conf.d/.

The problem I was having (until now I hope) is the following:

At startup ipfilter rules would get loaded normally. However, when it 
was ipnat's turn to be configured, it would not detect that ipfilter was 
enabled per rc config. It then proceeded to try to activate ipfilter 
when it already was active (minor annoyance). Additionally, it would 
flush the previously loaded ipfilter rules (big annoyance with 
default-block ipf). This is because of the following lines in 
/etc/rc.d/ipnat:

    if ! checkyesno ipfilter || [ ! -f /etc/ipf.conf ]; then
       echo "Enabling ipfilter for NAT."
       /sbin/ipf -E -Fa
    fi

The problem as I see it: load_rc_config() at the end of /etc/rc.d/ipnat 
only loads /etc/rc.conf plus the relevant config out of /etc/rc.conf.d/ 
for _that script only_. Since I keep all my configs modular neither 
/etc/rc.conf nor /etc/rc.conf.d/ipnat set $ipfilter.

I worked around the problem by using one of 2 ways:

1. Modify /etc/rc.conf.d/ipnat to also contain ipfilter="YES"

Re: none

"Bruce J.A. Nourish" <bjan+tech-userlevel <at> bjan.net> writes:
> misc/11011: points out that when bringing a laptop up from several
> days or more of bieng suspended, the daily/weekly scripts immediately
> kick in and start several very battery-expensive operations (i.e.
> find / ...). John Hawkinson replied, suggesting that the multiple
> find / operations could probably be eliminated, and mentioned some
> other problems with daily/weekly scripts on laptops.

We tweaked cron to fix this years ago.

--

-- 
Perry E. Metzger		perry <at> piermont.com

pppoe(4) man page in conjunction with Postfix leaves gaping relay hole

Hi,

the pppoe(4) man page suggests:

EXAMPLES
      A typical /etc/ifconfig.pppoe0 file looks like this:

            [...]
            inet 0.0.0.0 0.0.0.1
            [...]

At first, I simply adopted this example, with the effect that my pppoe0
interface had a netmask of 0xff000000. This went completely unnoticed. I
also run Postfix. As per Postfix' default configuration ($mynetworks
parameter):

# You can specify the list of "trusted" network addresses by hand
# or you can let Postfix do it for you (which is the default).

This means Postfix looks at each interface and uses the ip/mask as an
indication of trust to allow relaying. I only noticed this when doing
postconf(1) one day to browse through options wrt fixing another problem.

I think it's clear that with a pppoe0 interface with mask 0xff000000 any
user of your provider (and likely more) is allowed to relay through you
per default, which is unacceptable imho.

The pppoectl(8) man page makes the same mistake. Simply adding 'netmask
0xffffffff' to the above /etc/ifconfig.pppoe0 line fixes this and should
be reflected in the man pages, especially in examples that newbies like

Re: pppoe(4) man page in conjunction with Postfix leaves gaping relay hole

> the pppoe(4) man page suggests:
> 
> EXAMPLES
>       A typical /etc/ifconfig.pppoe0 file looks like this:
> 
>             [...]
>             inet 0.0.0.0 0.0.0.1
>             [...]
> 
> At first, I simply adopted this example, with the effect that my pppoe0
> interface had a netmask of 0xff000000. This went completely unnoticed. I
> also run Postfix. As per Postfix' default configuration ($mynetworks
> parameter):
> 
> # You can specify the list of "trusted" network addresses by hand
> # or you can let Postfix do it for you (which is the default).
> 
> This means Postfix looks at each interface and uses the ip/mask as an
> indication of trust to allow relaying. I only noticed this when doing
> postconf(1) one day to browse through options wrt fixing another problem.
> 
> I think it's clear that with a pppoe0 interface with mask 0xff000000 any
> user of your provider (and likely more) is allowed to relay through you
> per default, which is unacceptable imho.

	0.0.0.0/8 will not match any source address.  am i mistaken?

itojun

Re: pppoe(4) man page in conjunction with Postfix leaves gaping relay hole

Jun-ichiro itojun Hagino wrote:
> 	0.0.0.0/8 will not match any source address.  am i mistaken?
> 
> itojun

You are not. However, upon establishing a successful pppoe link the 
result looks like this

    inet 80.130.149.14 -> 217.5.98.29 netmask 0xff000000

which causes Postfix to treat 80.0.0.0/8 as a trusted network to relay for.

--

-- 
Of course it runs NetBSD.

PGP key: 42A5E773 / 41DE 4A4C DB34 33F7 2044  8FE0 91AA C584 42A5 E773

Re: pppoe(4) man page in conjunction with Postfix leaves gaping relay hole

Sorry for the double reply. Wasn't meaning to post from a different 
identity. I'm a bit out of my mind *sigh*.

To clarify: pppoe(4) uses the 0.0.0.0 and 0.0.0.1 addresses as 
placeholders when setting the interface up, since some ip addresses have 
to be specified. When establishing the real link, these get replaced by 
the client address and the peer's address. Sorry for the confusion. The 
issue remains.

--

-- 
Of course it runs NetBSD.

PGP key: 42A5E773 / 41DE 4A4C DB34 33F7 2044  8FE0 91AA C584 42A5 E773

Re: pppoe(4) man page in conjunction with Postfix leaves gaping relay hole

> Jun-ichiro itojun Hagino wrote:
> > 	0.0.0.0/8 will not match any source address.  am i mistaken?
> You are not. However, upon establishing a successful pppoe link the 
> result looks like this
>     inet 80.130.149.14 -> 217.5.98.29 netmask 0xff000000
> which causes Postfix to treat 80.0.0.0/8 as a trusted network to relay for.

	now i see the problem.  yes, it has to be fixed (documentation fix only
	i suppose).

itojun

Re: pppoe(4) man page in conjunction with Postfix leaves gaping relay hole

> > Jun-ichiro itojun Hagino wrote:
> > > 	0.0.0.0/8 will not match any source address.  am i mistaken?
> > You are not. However, upon establishing a successful pppoe link the 
> > result looks like this
> >     inet 80.130.149.14 -> 217.5.98.29 netmask 0xff000000
> > which causes Postfix to treat 80.0.0.0/8 as a trusted network to relay for.
> 
> 	now i see the problem.  yes, it has to be fixed (documentation fix only
> 	i suppose).

	does it address your problem?

itojun

Index: if_spppsubr.c
===================================================================
RCS file: /cvsroot/src/sys/net/if_spppsubr.c,v
retrieving revision 1.69
diff -u -r1.69 if_spppsubr.c
--- if_spppsubr.c	5 Sep 2003 23:02:41 -0000	1.69
+++ if_spppsubr.c	2 Oct 2003 01:26:12 -0000
 <at>  <at>  -2514,7 +2514,7  <at>  <at> 
 	else
 		sp->pp_phase = SPPP_PHASE_NETWORK;

-	if(debug)
+	if (debug)
 	{
 		log(LOG_INFO, "%s: phase %s\n", ifp->if_xname,