Re: mention /etc/examples/ in bgpf.conf(5)/bgpd(8)

2020-02-08 Thread Jason McIntyre
On Sun, Feb 09, 2020 at 01:15:59AM +0100, Ingo Schwarze wrote:
> Hi,
> 
> Theo de Raadt wrote on Sat, Feb 08, 2020 at 04:39:42PM -0700:
> 
> > For complicated configurations, the text could explain the reason the
> > example is valuable -- for instance
> > 
> > .It Pa /etc/examples/bgpd.conf
> > Example configuration file demonstrating IBGP mesh, multiple transits,
> > RPKI filtering, and other best practices.
> 
> I like that.  It gives the reader an idea of how interesting the file
> might be without even opening it.
> 
> We have to be careful to not make the comment too long, or FILES
> might look bad, but your text still looks reasonable to me.
> 
> I think it's sufficient to have this wording in bgpd.conf(5);
> in bgpd(8), mentioning the existence of the example seems fair, but
> the exact contents seem more tangential there.  I guess network
> admins running that beast will have to look at bgpd.conf(5) anyway.
> 
> 
> I applied Jason's recommendation to remove the "do not edit";
> probably he is right that it isn't required.
> 
> Regarding benno@'s comment:  /etc/exanmples/ is already mentioned
> in hier(7) and yet some people missed it.  I wouldn't blame them.
> Also, you don't really need to look into /etc/examples/ for all
> programs; if we point to it from where it matters, that's even
> better usability.  Still, i think it would *also* make sense to
> mention the directory in a FILES section in help(1), and optionally
> also in afterboot(8), though the latter seems less relevant.  I'm
> not feeling strongly about that, and one doesn't exclude the other.
> Pointers are cheap and can be added whereever they help, only not
> in such an amount that they would become a distraction.
> 
> Updated patch: still OK?
>   Ingo
> 

morning.

here's some issues i see. i'll concentrate on bgpd to keep it simple:

- bgpd.8 refers to /etc/bgpd.conf. that file doesn;t exist by default.
- i'm not convinced bgpd.8 needs to refer to the example file.
- only root can view the example file. i understand why, but in itself
  it's not that helpful.
- we've seen from this thread that people are missing the existence of
  /etc/examples/bgpd.conf. that's a shame because it looks like a nicely
  written file.

the essential issue is we want people to find the examples. the least
amount of work to achieve that is just for bgpd.conf.5 to mention it.
adding extra stuff about what's in there is a lot of work and sets us up
for things going out of date in the future. and although it might work
well for bgpd - a big, complex, piece of software, it will probably make
less sense for most other software. leaving us with a divided strategy.

it'd be good to have a clear idea of which pages we're planning to
change, and how, so that it's clear for other authors.

for bgpd i propose:

- no change to bgpd.8. i don;t have a solution to the fact that we moved
  its config file to examples/ so there isn;t an /etc/bgpd.conf file. i
  suppose everyone understands what is happening.
- for bgpd.conf.5, add an entry to FILES "example configuration file".
  no more.
- i'm not the right person to judge the existence of individual example
  files. ratchov already indicated he doesn;t see the point of
  examples/mixerctl.conf. i guess individual devs get to judge this.
- i think an addition to afterboot.8 totally makes sense. it's what it's
  there for.
- i don;t think an addition to help.1 makes sense. that is just trying
  to tell people how to use unix, and no one reads it anyway.

jmc

> 
> Index: bgpd.8
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.8,v
> retrieving revision 1.62
> diff -u -p -r1.62 bgpd.8
> --- bgpd.810 Nov 2019 20:51:53 -  1.62
> +++ bgpd.88 Feb 2020 23:52:00 -
> @@ -205,11 +205,13 @@ Only check the configuration file for va
>  Produce more verbose output.
>  .El
>  .Sh FILES
> -.Bl -tag -width "/var/run/bgpd.sockXXX" -compact
> +.Bl -tag -width "/etc/examples/bgpd.conf" -compact
>  .It Pa /etc/bgpd.conf
>  default
>  .Nm
>  configuration file
> +.It Pa /etc/examples/bgpd.conf
> +example configuration file
>  .It Pa /var/run/bgpd.sock
>  default
>  .Nm
> Index: bgpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> retrieving revision 1.199
> diff -u -p -r1.199 bgpd.conf.5
> --- bgpd.conf.5   25 Jan 2020 12:07:28 -  1.199
> +++ bgpd.conf.5   8 Feb 2020 23:52:00 -
> @@ -1883,10 +1883,13 @@ For prefixes with equally long paths, th
>  is selected.
>  .El
>  .Sh FILES
> -.Bl -tag -width "/etc/bgpd.conf" -compact
> +.Bl -tag -width "/etc/examples/bgpd.conf" -compact
>  .It Pa /etc/bgpd.conf
>  .Xr bgpd 8
>  configuration file
> +.It Pa /etc/examples/bgpd.conf
> +example configuration file demonstrating IBGP mesh, multiple transits,
> +RPKI filtering, and other best practices
>  .El
>  .Sh SEE ALSO
>  .Xr strftime 3 ,
> 



Re: get rid of almost empty /etc/examples/mixerctl.conf

2020-02-08 Thread Alexandre Ratchov
On Sat, Feb 08, 2020 at 11:04:10PM +0100, Ingo Schwarze wrote:
> Hi Theo,
> 
> you have a point, that was a lot of cheap talk and no patch.
> 
> I don't aim at changing yacc(1) grammars.  I think most parts of
> OpenBSD configuration systems already have sane defaults and most
> configuration syntaxes are already good with respect to simplicity
> and usability.  At least "most", maybe even all.
> 
> > The example files were moved from /etc, so that /etc contained fewer
> > files for unconfigured software.
> 
> That was a very good step, and it was also good to not encumber it
> by trying to do more at the same time.
> 
> > Little to no effort was put into curating them.  That's the gap that
> > occured.
> 
> So, here i'm putting a few pennies where my mouth is, starting from the
> shortest file in /etc/examples/.  The example is so short that cut and
> paste from the manual page will certainly cause no trouble, and the
> file also isn't a special case with respect to permissions,
> it is -rw-r--r-- root:wheel.
> 
> OK?
>   Ingo
> 
> 
> P.S.
> When preparing this, i noticed i already had the change to
> mixerctl.conf.5 in my tree.  It looks like i started it
> in the past, then forgot about it.
> 
> P.P.S.
> Note that i will not propose to get rid of *all* of /etc/examples/,
> but just of trivial examples that provide no benefit by being outside
> the manual page.  There are certainly some that make sense as they
> are.

I agree that the mixerctl.conf is pointless. Furthermore not all
devices have an outputs.master knob (ex. envy(4) and uaudio(4) don't),
so the example is wrong in certain cases.

thanks for looking at this

ok ratchov



Re: mention /etc/examples/ in bgpf.conf(5)/bgpd(8)

2020-02-08 Thread Theo de Raadt
Ingo Schwarze  wrote:

> Theo de Raadt wrote on Sat, Feb 08, 2020 at 04:39:42PM -0700:
> 
> > For complicated configurations, the text could explain the reason the
> > example is valuable -- for instance
> > 
> > .It Pa /etc/examples/bgpd.conf
> > Example configuration file demonstrating IBGP mesh, multiple transits,
> > RPKI filtering, and other best practices.
> 
> I like that.  It gives the reader an idea of how interesting the file
> might be without even opening it.

Additionally, it puts them best-foot-forward.

A list of "this is what you can do" is not the same as an example which
uses the correct features.  In example bgpd.conf this is very clear.

If we improve other examples, they could also become more valuable.



Re: mention /etc/examples/ in bgpf.conf(5)/bgpd(8)

2020-02-08 Thread Ingo Schwarze
Hi,

Theo de Raadt wrote on Sat, Feb 08, 2020 at 04:39:42PM -0700:

> For complicated configurations, the text could explain the reason the
> example is valuable -- for instance
> 
> .It Pa /etc/examples/bgpd.conf
> Example configuration file demonstrating IBGP mesh, multiple transits,
> RPKI filtering, and other best practices.

I like that.  It gives the reader an idea of how interesting the file
might be without even opening it.

We have to be careful to not make the comment too long, or FILES
might look bad, but your text still looks reasonable to me.

I think it's sufficient to have this wording in bgpd.conf(5);
in bgpd(8), mentioning the existence of the example seems fair, but
the exact contents seem more tangential there.  I guess network
admins running that beast will have to look at bgpd.conf(5) anyway.


I applied Jason's recommendation to remove the "do not edit";
probably he is right that it isn't required.

Regarding benno@'s comment:  /etc/exanmples/ is already mentioned
in hier(7) and yet some people missed it.  I wouldn't blame them.
Also, you don't really need to look into /etc/examples/ for all
programs; if we point to it from where it matters, that's even
better usability.  Still, i think it would *also* make sense to
mention the directory in a FILES section in help(1), and optionally
also in afterboot(8), though the latter seems less relevant.  I'm
not feeling strongly about that, and one doesn't exclude the other.
Pointers are cheap and can be added whereever they help, only not
in such an amount that they would become a distraction.

Updated patch: still OK?
  Ingo


Index: bgpd.8
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.8,v
retrieving revision 1.62
diff -u -p -r1.62 bgpd.8
--- bgpd.8  10 Nov 2019 20:51:53 -  1.62
+++ bgpd.8  8 Feb 2020 23:52:00 -
@@ -205,11 +205,13 @@ Only check the configuration file for va
 Produce more verbose output.
 .El
 .Sh FILES
-.Bl -tag -width "/var/run/bgpd.sockXXX" -compact
+.Bl -tag -width "/etc/examples/bgpd.conf" -compact
 .It Pa /etc/bgpd.conf
 default
 .Nm
 configuration file
+.It Pa /etc/examples/bgpd.conf
+example configuration file
 .It Pa /var/run/bgpd.sock
 default
 .Nm
Index: bgpd.conf.5
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
retrieving revision 1.199
diff -u -p -r1.199 bgpd.conf.5
--- bgpd.conf.5 25 Jan 2020 12:07:28 -  1.199
+++ bgpd.conf.5 8 Feb 2020 23:52:00 -
@@ -1883,10 +1883,13 @@ For prefixes with equally long paths, th
 is selected.
 .El
 .Sh FILES
-.Bl -tag -width "/etc/bgpd.conf" -compact
+.Bl -tag -width "/etc/examples/bgpd.conf" -compact
 .It Pa /etc/bgpd.conf
 .Xr bgpd 8
 configuration file
+.It Pa /etc/examples/bgpd.conf
+example configuration file demonstrating IBGP mesh, multiple transits,
+RPKI filtering, and other best practices
 .El
 .Sh SEE ALSO
 .Xr strftime 3 ,



Re: locate.updatedb TMPDIR

2020-02-08 Thread Joerg Jung
On Sun, Feb 09, 2020 at 12:33:42AM +0100, Joerg Jung wrote:
> Hi,
> 
> I have a machine with a large data storage attached, but it has only 2GB
> of /tmp (which I consider enough usually).  On this machine weekly
> locate.updatedb fails, due to /tmp being full.  To fix this I would like
> to point locate to a different TMPDIR.
>  
> But it seems one can not just set TMPDIR from /etc/locate.rc to point
> elsewhere, since command line args in /etc/weekly override
> /etc/locate.rc settings.

Below is a second diff, which tries to document that behaviour.
 
> While it's possible to add a weekly.local to set TMPDIR I believe it
> should be better set in the actual configuration file instead of 
> ignoring locate.rc.
> 
> Thus the diff below proposes to remove command line argument to be able
> to use /etc/locate.rc instead.
> 
> Note, this might break existing setups, where one has set TMPDIR in
> /etc/weekly.local to point elsewhere.  This might be handled with a
> -current upgrade entry?
> 
> Comments? OK?
> 
> Thanks,
> Regards,
> Joerg
> 
> 
> Index: etc/weekly
> ===
> RCS file: /cvs/src/etc/weekly,v
> retrieving revision 1.29
> diff -u -p -r1.29 weekly
> --- etc/weekly30 Dec 2019 16:49:51 -  1.29
> +++ etc/weekly8 Feb 2020 23:13:02 -
> @@ -48,7 +48,7 @@ if [ -f /var/db/locate.database ]; then
>   if TMP=`mktemp /var/db/locate.database.XX`; then
>   trap 'rm -f $TMP; exit 1' 0 1 15
>   UPDATEDB="/usr/libexec/locate.updatedb"
> - echo "${UPDATEDB} --fcodes=- --tmpdir=${TMPDIR:-/tmp}" | \
> + echo "${UPDATEDB} --fcodes=- | \
>   nice -5 su -m nobody 1>$TMP
>   if [ $? -ne 0 ]; then
>   echo "Rebuilding locate database failed"
> 


Index: usr.bin/locate/locate/locate.updatedb.8
===
RCS file: /cvs/src/usr.bin/locate/locate/locate.updatedb.8,v
retrieving revision 1.18
diff -u -p -r1.18 locate.updatedb.8
--- usr.bin/locate/locate/locate.updatedb.8 10 Dec 2009 00:45:43 -  
1.18
+++ usr.bin/locate/locate/locate.updatedb.8 8 Feb 2020 23:44:41 -
@@ -54,6 +54,7 @@ script.
 The contents of the newly built database can be controlled by the
 .Pa /etc/locate.rc
 file as well as the command line arguments.
+Command line arguments override rc file and defaults.
 .Pp
 The options are as follows:
 .Bl -tag -width Ds



Re: mention /etc/examples/ in bgpf.conf(5)/bgpd(8)

2020-02-08 Thread Jason McIntyre
On Sun, Feb 09, 2020 at 12:33:06AM +0100, Ingo Schwarze wrote:
> Hi,
> 
> Jason McIntyre wrote on Sat, Feb 08, 2020 at 10:15:08PM +:
> 
> > - i'm ok with adding the path to these files to a FILES section
> 
> So, here is a specific patch for bgpf.conf(5) and bgpd(8) such
> that we can agree on a general direction for one case where
> the example file is particularly important.
> 
> Once the direction is agreed, applying it to the relatively
> small number of other cases is likely not difficult.
> 
> OK?
>   Ingo
> 

i think it should just say sth like "example configuration file". i
don;t think we should say "do not edit": i hope people will understand
that they need to copy it over to /etc. i guess that is an issue with an
examples dir, but hopefully it is self explanatory.

jmc

> 
> Index: bgpd.8
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.8,v
> retrieving revision 1.62
> diff -u -p -r1.62 bgpd.8
> --- bgpd.810 Nov 2019 20:51:53 -  1.62
> +++ bgpd.88 Feb 2020 23:24:28 -
> @@ -205,11 +205,13 @@ Only check the configuration file for va
>  Produce more verbose output.
>  .El
>  .Sh FILES
> -.Bl -tag -width "/var/run/bgpd.sockXXX" -compact
> +.Bl -tag -width "/etc/examples/bgpd.conf" -compact
>  .It Pa /etc/bgpd.conf
>  default
>  .Nm
>  configuration file
> +.It Pa /etc/examples/bgpd.conf
> +example file, do not edit
>  .It Pa /var/run/bgpd.sock
>  default
>  .Nm
> Index: bgpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> retrieving revision 1.199
> diff -u -p -r1.199 bgpd.conf.5
> --- bgpd.conf.5   25 Jan 2020 12:07:28 -  1.199
> +++ bgpd.conf.5   8 Feb 2020 23:24:28 -
> @@ -1883,10 +1883,12 @@ For prefixes with equally long paths, th
>  is selected.
>  .El
>  .Sh FILES
> -.Bl -tag -width "/etc/bgpd.conf" -compact
> +.Bl -tag -width "/etc/examples/bgpd.conf" -compact
>  .It Pa /etc/bgpd.conf
>  .Xr bgpd 8
>  configuration file
> +.It Pa /etc/examples/bgpd.conf
> +example file, do not edit
>  .El
>  .Sh SEE ALSO
>  .Xr strftime 3 ,
> 



Re: mention /etc/examples/ in bgpf.conf(5)/bgpd(8)

2020-02-08 Thread Sebastian Benoit
Ingo Schwarze(schwa...@usta.de) on 2020.02.09 00:33:06 +0100:
> Hi,
> 
> Jason McIntyre wrote on Sat, Feb 08, 2020 at 10:15:08PM +:
> 
> > - i'm ok with adding the path to these files to a FILES section
> 
> So, here is a specific patch for bgpf.conf(5) and bgpd(8) such
> that we can agree on a general direction for one case where
> the example file is particularly important.
> 
> Once the direction is agreed, applying it to the relatively
> small number of other cases is likely not difficult.
> 
> OK?
>   Ingo

I'm not against this as it only adds to the manpage, but an
alternative could be to just tell users (in afterboot(8)?) that there is
/etc/examples for them to look at and see whats there?

Otherwise ok.


> Index: bgpd.8
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.8,v
> retrieving revision 1.62
> diff -u -p -r1.62 bgpd.8
> --- bgpd.810 Nov 2019 20:51:53 -  1.62
> +++ bgpd.88 Feb 2020 23:24:28 -
> @@ -205,11 +205,13 @@ Only check the configuration file for va
>  Produce more verbose output.
>  .El
>  .Sh FILES
> -.Bl -tag -width "/var/run/bgpd.sockXXX" -compact
> +.Bl -tag -width "/etc/examples/bgpd.conf" -compact
>  .It Pa /etc/bgpd.conf
>  default
>  .Nm
>  configuration file
> +.It Pa /etc/examples/bgpd.conf
> +example file, do not edit
>  .It Pa /var/run/bgpd.sock
>  default
>  .Nm
> Index: bgpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> retrieving revision 1.199
> diff -u -p -r1.199 bgpd.conf.5
> --- bgpd.conf.5   25 Jan 2020 12:07:28 -  1.199
> +++ bgpd.conf.5   8 Feb 2020 23:24:28 -
> @@ -1883,10 +1883,12 @@ For prefixes with equally long paths, th
>  is selected.
>  .El
>  .Sh FILES
> -.Bl -tag -width "/etc/bgpd.conf" -compact
> +.Bl -tag -width "/etc/examples/bgpd.conf" -compact
>  .It Pa /etc/bgpd.conf
>  .Xr bgpd 8
>  configuration file
> +.It Pa /etc/examples/bgpd.conf
> +example file, do not edit
>  .El
>  .Sh SEE ALSO
>  .Xr strftime 3 ,
> 



Re: mention /etc/examples/ in bgpf.conf(5)/bgpd(8)

2020-02-08 Thread Theo de Raadt
For complicated configurations, the text could explain the reason the
example is valuable -- for instance

+.It Pa /etc/examples/bgpd.conf
Example configuration file demonstrating IBGP mesh, multiple transits,
RPKI filtering, and other best practices.


The same idea can carry to other files. I've already provided some
similar words for the httpd.conf example...

> So, here is a specific patch for bgpf.conf(5) and bgpd(8) such
> that we can agree on a general direction for one case where
> the example file is particularly important.
> 
> Once the direction is agreed, applying it to the relatively
> small number of other cases is likely not difficult.
> 
> OK?
>   Ingo
> 
> 
> Index: bgpd.8
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.8,v
> retrieving revision 1.62
> diff -u -p -r1.62 bgpd.8
> --- bgpd.810 Nov 2019 20:51:53 -  1.62
> +++ bgpd.88 Feb 2020 23:24:28 -
> @@ -205,11 +205,13 @@ Only check the configuration file for va
>  Produce more verbose output.
>  .El
>  .Sh FILES
> -.Bl -tag -width "/var/run/bgpd.sockXXX" -compact
> +.Bl -tag -width "/etc/examples/bgpd.conf" -compact
>  .It Pa /etc/bgpd.conf
>  default
>  .Nm
>  configuration file
> +.It Pa /etc/examples/bgpd.conf
> +example file, do not edit
>  .It Pa /var/run/bgpd.sock
>  default
>  .Nm
> Index: bgpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> retrieving revision 1.199
> diff -u -p -r1.199 bgpd.conf.5
> --- bgpd.conf.5   25 Jan 2020 12:07:28 -  1.199
> +++ bgpd.conf.5   8 Feb 2020 23:24:28 -
> @@ -1883,10 +1883,12 @@ For prefixes with equally long paths, th
>  is selected.
>  .El
>  .Sh FILES
> -.Bl -tag -width "/etc/bgpd.conf" -compact
> +.Bl -tag -width "/etc/examples/bgpd.conf" -compact
>  .It Pa /etc/bgpd.conf
>  .Xr bgpd 8
>  configuration file
> +.It Pa /etc/examples/bgpd.conf
> +example file, do not edit
>  .El
>  .Sh SEE ALSO
>  .Xr strftime 3 ,
> 



locate.updatedb TMPDIR

2020-02-08 Thread Joerg Jung
Hi,

I have a machine with a large data storage attached, but it has only 2GB
of /tmp (which I consider enough usually).  On this machine weekly
locate.updatedb fails, due to /tmp being full.  To fix this I would like
to point locate to a different TMPDIR.
 
But it seems one can not just set TMPDIR from /etc/locate.rc to point
elsewhere, since command line args in /etc/weekly override
/etc/locate.rc settings.

While it's possible to add a weekly.local to set TMPDIR I believe it
should be better set in the actual configuration file instead of 
ignoring locate.rc.

Thus the diff below proposes to remove command line argument to be able
to use /etc/locate.rc instead.

Note, this might break existing setups, where one has set TMPDIR in
/etc/weekly.local to point elsewhere.  This might be handled with a
-current upgrade entry?

Comments? OK?

Thanks,
Regards,
Joerg


Index: etc/weekly
===
RCS file: /cvs/src/etc/weekly,v
retrieving revision 1.29
diff -u -p -r1.29 weekly
--- etc/weekly  30 Dec 2019 16:49:51 -  1.29
+++ etc/weekly  8 Feb 2020 23:13:02 -
@@ -48,7 +48,7 @@ if [ -f /var/db/locate.database ]; then
if TMP=`mktemp /var/db/locate.database.XX`; then
trap 'rm -f $TMP; exit 1' 0 1 15
UPDATEDB="/usr/libexec/locate.updatedb"
-   echo "${UPDATEDB} --fcodes=- --tmpdir=${TMPDIR:-/tmp}" | \
+   echo "${UPDATEDB} --fcodes=- | \
nice -5 su -m nobody 1>$TMP
if [ $? -ne 0 ]; then
echo "Rebuilding locate database failed"



mention /etc/examples/ in bgpf.conf(5)/bgpd(8)

2020-02-08 Thread Ingo Schwarze
Hi,

Jason McIntyre wrote on Sat, Feb 08, 2020 at 10:15:08PM +:

> - i'm ok with adding the path to these files to a FILES section

So, here is a specific patch for bgpf.conf(5) and bgpd(8) such
that we can agree on a general direction for one case where
the example file is particularly important.

Once the direction is agreed, applying it to the relatively
small number of other cases is likely not difficult.

OK?
  Ingo


Index: bgpd.8
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.8,v
retrieving revision 1.62
diff -u -p -r1.62 bgpd.8
--- bgpd.8  10 Nov 2019 20:51:53 -  1.62
+++ bgpd.8  8 Feb 2020 23:24:28 -
@@ -205,11 +205,13 @@ Only check the configuration file for va
 Produce more verbose output.
 .El
 .Sh FILES
-.Bl -tag -width "/var/run/bgpd.sockXXX" -compact
+.Bl -tag -width "/etc/examples/bgpd.conf" -compact
 .It Pa /etc/bgpd.conf
 default
 .Nm
 configuration file
+.It Pa /etc/examples/bgpd.conf
+example file, do not edit
 .It Pa /var/run/bgpd.sock
 default
 .Nm
Index: bgpd.conf.5
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
retrieving revision 1.199
diff -u -p -r1.199 bgpd.conf.5
--- bgpd.conf.5 25 Jan 2020 12:07:28 -  1.199
+++ bgpd.conf.5 8 Feb 2020 23:24:28 -
@@ -1883,10 +1883,12 @@ For prefixes with equally long paths, th
 is selected.
 .El
 .Sh FILES
-.Bl -tag -width "/etc/bgpd.conf" -compact
+.Bl -tag -width "/etc/examples/bgpd.conf" -compact
 .It Pa /etc/bgpd.conf
 .Xr bgpd 8
 configuration file
+.It Pa /etc/examples/bgpd.conf
+example file, do not edit
 .El
 .Sh SEE ALSO
 .Xr strftime 3 ,



Re: get rid of almost empty /etc/examples/mixerctl.conf

2020-02-08 Thread Theo de Raadt
Ingo Schwarze  wrote:

> Indeed.  When i talk about quality of documentation - which i did
> at multiple conferences, last time 2018 in Bucuresti - one of the
> first sentences i almost always say is:
> 
>   Documentation must be correct, complete, concise, all in one
>   place, marked up for display and search, easy to read, and easy
>   to write.
> 
>   e.g. https://www.openbsd.org/papers/eurobsdcon2018-mandoc.pdf
>   first page after the title, second bullet point
> 
> The "all in one place" part has two purposes: convenience for the
> user to not have to search multiple places to find it and convenience
> for the developer to not have to maintain duplicate information.

It doesn't say

   and to get us there other sources of information must excluded
   and exterminated

> As long as the manuals are complete and somebody voluntarily
> maintains the examples, which seems the case for now, there is
> not much harm from the duplication during the time we lack full
> consensus.

A good example is the httpd.conf example.  In your world, someone
must read and completely understand a 500-line manual page, and
make several difficult inferences and tests, to get close to the
resulting example which is a http/https front-end capable of bouncing
ACME refresh requests.

Noone will arrive there by reading the man page once.  Noone will get
there in less than an hour.  Non-native english readers won't succeed
will take even longer.  So they'll go use other software.  Such strict
approaches easily turn into a strong turnoff.  A strict policy improving
man page quality is one thing, but a policy removing useful short is
crazy, and connecting this to manual page quality dissapoints me.  t is
almost as if the hate for HOWTO has derailed into "you must read our
beautiful prose" -- all other approaches indicate user weakness.





Re: get rid of almost empty /etc/examples/mixerctl.conf

2020-02-08 Thread Ingo Schwarze
Hi Theo,

Theo de Raadt wrote on Sat, Feb 08, 2020 at 03:33:37PM -0700:
> Jason McIntyre  wrote:
 
>> without getting into a discussion about /etc/examples, in this case i
>> personally see neither the point of the example config file (so trivial
>> as to be questionable) nor the addition to the man page (if the example
>> is worthwhile, add it to mixerctl, not the conf page).

> there is additional pieces of "documentation" that occurs here
> 
> - this is a filename, which if placed one directory above., would
>   perform a function
> - the comment format of the file is demonstrated
> - the basic format of the file is demonstrated (is it simply a series
>   of name=value, or have we created a richer DSL)
> 
> you can argue that is in the manual page.  It is.  After you read a
> lot more.  There is a pace-of-learning going on here.  Noone ever
> demanded that learning must come from a man page, additional sources
> of transient information are not prohibited, but I'm picking up a
> disdain for information learned any other way...

Indeed.  When i talk about quality of documentation - which i did
at multiple conferences, last time 2018 in Bucuresti - one of the
first sentences i almost always say is:

  Documentation must be correct, complete, concise, all in one
  place, marked up for display and search, easy to read, and easy
  to write.

  e.g. https://www.openbsd.org/papers/eurobsdcon2018-mandoc.pdf
  first page after the title, second bullet point

The "all in one place" part has two purposes: convenience for the
user to not have to search multiple places to find it and convenience
for the developer to not have to maintain duplicate information.

Of course, you have valid points that examples can be particularly
fast for picking up information (when they are short and unless you
happen to draw incorrect conclusions from them) and that copy-and-paste
can matter.

So, if there is no clear consensus about which arguments matter how
much, we probably best leave /etc/examples/ alone.  I doubt having
a prolonged fight over this is a smart idea.

As long as the manuals are complete and somebody voluntarily
maintains the examples, which seems the case for now, there is
not much harm from the duplication during the time we lack full
consensus.

Yours,
  Ingo



Re: httpd(8): patch to allow FastCGI chroots in sub-directories

2020-02-08 Thread Sebastian Benoit
ok

Florian Obser(flor...@openbsd.org) on 2020.02.07 16:49:08 +0100:
> Slightly tweaked diff by me, fixing "new sentence new line" in the man
> page.
> 
> This is OK florian@ if someone wants to commit it or I can commit it
> if someone OKs it.
> 
> diff --git httpd.conf.5 httpd.conf.5
> index f4ea2e55766..494271672ea 100644
> --- httpd.conf.5
> +++ httpd.conf.5
> @@ -300,6 +300,12 @@ Alternatively if
>  the FastCGI handler is listening on a TCP socket,
>  .Ar socket
>  starts with a colon followed by the TCP port number.
> +.It Ic strip Ar number
> +Strip
> +.Ar number
> +path components from the beginning of DOCUMENT_ROOT and
> +SCRIPT_FILENAME before sending them to the FastCGI server.
> +This allows FastCGI server chroot to be a directory under httpd chroot.
>  .It Ic param Ar variable value
>  Sets a variable that will be sent to the FastCGI server.
>  Each statement defines one variable.
> diff --git httpd.h httpd.h
> index b1f17af8cd7..b22586974a5 100644
> --- httpd.h
> +++ httpd.h
> @@ -547,6 +547,7 @@ struct server_config {
>   uint8_t  hsts_flags;
>  
>   struct server_fcgiparams fcgiparams;
> + int  fcgistrip;
>  
>   TAILQ_ENTRY(server_config) entry;
>  };
> diff --git parse.y parse.y
> index 054302269f4..109efd36a9f 100644
> --- parse.y
> +++ parse.y
> @@ -689,6 +689,13 @@ fcgiflags: SOCKET STRING {
>   param->name, param->value);
>   TAILQ_INSERT_HEAD(_conf->fcgiparams, param, entry);
>   }
> + | STRIP NUMBER  {
> + if ($2 < 0 || $2 > INT_MAX) {
> + yyerror("invalid fastcgi strip number");
> + YYERROR;
> + }
> + srv_conf->fcgistrip = $2;
> + }
>   ;
>  
>  connection   : CONNECTION '{' optnl conflags_l '}'
> diff --git server_fcgi.c server_fcgi.c
> index 864ce6b16d5..a85b5b44804 100644
> --- server_fcgi.c
> +++ server_fcgi.c
> @@ -241,7 +241,8 @@ server_fcgi(struct httpd *env, struct client *clt)
>   errstr = "failed to encode param";
>   goto fail;
>   }
> - if (fcgi_add_param(, "SCRIPT_FILENAME", script, clt) == -1) {
> + if (fcgi_add_param(, "SCRIPT_FILENAME", server_root_strip(script,
> + srv_conf->fcgistrip), clt) == -1) {
>   errstr = "failed to encode param";
>   goto fail;
>   }
> @@ -257,8 +258,8 @@ server_fcgi(struct httpd *env, struct client *clt)
>   goto fail;
>   }
>  
> - if (fcgi_add_param(, "DOCUMENT_ROOT", srv_conf->root,
> - clt) == -1) {
> + if (fcgi_add_param(, "DOCUMENT_ROOT", server_root_strip(
> + srv_conf->root, srv_conf->fcgistrip), clt) == -1) {
>   errstr = "failed to encode param";
>   goto fail;
>   }
> 
> 
> On Sat, Jan 18, 2020 at 07:19:33AM +0100, Nazar Zhuk wrote:
> > On Tue, Jan 14, 2020 at 03:07:05PM +0100, Florian Obser wrote:
> > > I like the idea. Unfortunately the diff does not apply.
> > Looks like I had formatting issues there. This should apply cleanly now.
> > 
> > 
> > Index: usr.sbin/httpd/httpd.conf.5
> > ===
> > RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> > retrieving revision 1.107
> > diff -u -p -u -r1.107 httpd.conf.5
> > --- usr.sbin/httpd/httpd.conf.5 8 May 2019 21:46:56 -   1.107
> > +++ usr.sbin/httpd/httpd.conf.5 17 Jan 2020 06:20:14 -
> > @@ -300,6 +300,10 @@ Alternatively if
> >  the FastCGI handler is listening on a TCP socket,
> >  .Ar socket
> >  starts with a colon followed by the TCP port number.
> > +.It Ic strip Ar number
> > +Strip
> > +.Ar number
> > +path components from the beginning of DOCUMENT_ROOT and SCRIPT_FILENAME 
> > before sending them to the FastCGI server. This allows FastCGI server 
> > chroot to be a directory under httpd chroot.
> >  .It Ic param Ar variable value
> >  Sets a variable that will be sent to the FastCGI server.
> >  Each statement defines one variable.
> > Index: usr.sbin/httpd/httpd.h
> > ===
> > RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
> > retrieving revision 1.145
> > diff -u -p -u -r1.145 httpd.h
> > --- usr.sbin/httpd/httpd.h  8 May 2019 19:57:45 -   1.145
> > +++ usr.sbin/httpd/httpd.h  17 Jan 2020 06:20:14 -
> > @@ -547,6 +547,7 @@ struct server_config {
> > uint8_t  hsts_flags;
> >  
> > struct server_fcgiparams fcgiparams;
> > +   int  fcgistrip;
> >  
> > TAILQ_ENTRY(server_config) entry;
> >  };
> > Index: usr.sbin/httpd/parse.y
> > ===
> > RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
> > retrieving revision 1.113
> > diff -u -p -u -r1.113 parse.y
> > --- usr.sbin/httpd/parse.y  28 Jun 

Re: get rid of almost empty /etc/examples/mixerctl.conf

2020-02-08 Thread Jason McIntyre
On Sat, Feb 08, 2020 at 03:33:37PM -0700, Theo de Raadt wrote:
> Jason McIntyre  wrote:
> 
> > without getting into a discussion about /etc/examples, in this case i
> > personally see neither the point of the example config file (so trivial
> > as to be questionable) nor the addition to the man page (if the example
> > is worthwhile, add it to mixerctl, not the conf page).
> 
> there is additional pieces of "documentation" that occurs here
> 
> - this is a filename, which if placed one directory above., would
>   perform a function

yep. so the reference in FILES makes sense. but could confuse the reader
too (because an example in top level /etc is no longer provided). i don;t
currently have a solution to that issue.

> - the comment format of the file is demonstrated

yep. but the comment format is pretty much universal and not needed for
demonstration.

> - the basic format of the file is demonstrated (is it simply a series
>   of name=value, or have we created a richer DSL)
> 

yep.

> you can argue that is in the manual page.  It is.  After you read a
> lot more.  There is a pace-of-learning going on here.  Noone ever

it's in the first paragraph

> demanded that learning must come from a man page, additional sources
> of transient information are not prohibited, but I'm picking up a
> disdain for information learned any other way...
> 

i don;t think it's disdain. just a discussion about how to get the info
across effectively. that the discussion began is maybe evidence that we
haven;t nailed it/.

jmc



Re: get rid of almost empty /etc/examples/mixerctl.conf

2020-02-08 Thread Joerg Jung
On Sat, Feb 08, 2020 at 03:33:37PM -0700, Theo de Raadt wrote:
> Jason McIntyre  wrote:
> 
> > without getting into a discussion about /etc/examples, in this case i
> > personally see neither the point of the example config file (so trivial
> > as to be questionable) nor the addition to the man page (if the example
> > is worthwhile, add it to mixerctl, not the conf page).
> 
> there is additional pieces of "documentation" that occurs here
> 
> - this is a filename, which if placed one directory above., would
>   perform a function
> - the comment format of the file is demonstrated
> - the basic format of the file is demonstrated (is it simply a series
>   of name=value, or have we created a richer DSL)

  - points out common use case
 
> you can argue that is in the manual page.  It is.  After you read a
> lot more.  There is a pace-of-learning going on here.  Noone ever
> demanded that learning must come from a man page, additional sources
> of transient information are not prohibited, but I'm picking up a
> disdain for information learned any other way...

I agree with that, personally I find /etc/examples/ helpful.



Re: get rid of almost empty /etc/examples/mixerctl.conf

2020-02-08 Thread Theo de Raadt
Jason McIntyre  wrote:

> without getting into a discussion about /etc/examples, in this case i
> personally see neither the point of the example config file (so trivial
> as to be questionable) nor the addition to the man page (if the example
> is worthwhile, add it to mixerctl, not the conf page).

there is additional pieces of "documentation" that occurs here

- this is a filename, which if placed one directory above., would
  perform a function
- the comment format of the file is demonstrated
- the basic format of the file is demonstrated (is it simply a series
  of name=value, or have we created a richer DSL)

you can argue that is in the manual page.  It is.  After you read a
lot more.  There is a pace-of-learning going on here.  Noone ever
demanded that learning must come from a man page, additional sources
of transient information are not prohibited, but I'm picking up a
disdain for information learned any other way...



Re: get rid of almost empty /etc/examples/mixerctl.conf

2020-02-08 Thread Jason McIntyre
On Sat, Feb 08, 2020 at 11:04:10PM +0100, Ingo Schwarze wrote:
> Hi Theo,
> 
> you have a point, that was a lot of cheap talk and no patch.
> 
> I don't aim at changing yacc(1) grammars.  I think most parts of
> OpenBSD configuration systems already have sane defaults and most
> configuration syntaxes are already good with respect to simplicity
> and usability.  At least "most", maybe even all.
> 
> > The example files were moved from /etc, so that /etc contained fewer
> > files for unconfigured software.
> 
> That was a very good step, and it was also good to not encumber it
> by trying to do more at the same time.
> 
> > Little to no effort was put into curating them.  That's the gap that
> > occured.
> 
> So, here i'm putting a few pennies where my mouth is, starting from the
> shortest file in /etc/examples/.  The example is so short that cut and
> paste from the manual page will certainly cause no trouble, and the
> file also isn't a special case with respect to permissions,
> it is -rw-r--r-- root:wheel.
> 
> OK?
>   Ingo
> 
> 
> P.S.
> When preparing this, i noticed i already had the change to
> mixerctl.conf.5 in my tree.  It looks like i started it
> in the past, then forgot about it.
> 
> P.P.S.
> Note that i will not propose to get rid of *all* of /etc/examples/,
> but just of trivial examples that provide no benefit by being outside
> the manual page.  There are certainly some that make sense as they
> are.
> 
> 
> Index: etc/Makefile
> ===
> RCS file: /cvs/src/etc/Makefile,v
> retrieving revision 1.477
> diff -u -p -r1.477 Makefile
> --- etc/Makefile  24 Jan 2020 06:17:37 -  1.477
> +++ etc/Makefile  8 Feb 2020 21:42:14 -
> @@ -46,7 +46,7 @@ MUTABLE=changelist daily etc.${MACHINE}/
>  
>  # -rw-r--r--
>  EXAMPLES=acme-client.conf chio.conf dhclient.conf dhcpd.conf exports \
> - httpd.conf ifstated.conf inetd.conf man.conf mixerctl.conf \
> + httpd.conf ifstated.conf inetd.conf man.conf \
>   mrouted.conf ntpd.conf printcap rad.conf rbootd.conf \
>   remote sensorsd.conf wsconsctl.conf
>  
> Index: share/man/man5/mixerctl.conf.5
> ===
> RCS file: /cvs/src/share/man/man5/mixerctl.conf.5,v
> retrieving revision 1.7
> diff -u -p -r1.7 mixerctl.conf.5
> --- share/man/man5/mixerctl.conf.530 Jul 2018 17:24:24 -  1.7
> +++ share/man/man5/mixerctl.conf.58 Feb 2020 21:42:14 -
> @@ -141,6 +141,11 @@ Default audio mixing device.
>  .Xr mixerctl 1
>  configuration file.
>  .El
> +.Sh EXAMPLES
> +Most audio cards support setting the output volume by adding this line to
> +.Nm :
> +.Pp
> +.Dl outputs.master=200
>  .Sh SEE ALSO
>  .Xr aucat 1 ,
>  .Xr audioctl 1 ,
> Index: etc/examples/mixerctl.conf
> ===
> RCS file: etc/examples/mixerctl.conf
> diff -N etc/examples/mixerctl.conf
> --- etc/examples/mixerctl.conf16 Jul 2014 13:21:33 -  1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,7 +0,0 @@
> -# $OpenBSD: mixerctl.conf,v 1.1 2014/07/16 13:21:33 deraadt Exp $
> -#
> -# mixerctl(1) configurable parameters. See mixerctl.conf(5) for details.
> -#
> -
> -# output volume value for most audio cards
> -#outputs.master=200

without getting into a discussion about /etc/examples, in this case i
personally see neither the point of the example config file (so trivial
as to be questionable) nor the addition to the man page (if the example
is worthwhile, add it to mixerctl, not the conf page).

surely stuff like this is self explanatory.

note that mixerctl.conf.5 has an entry in FILES for /etc/mixerctl.conf
(non-existent by default) but not /etc/examples/mixerctl.conf (which
does exist). i guess whatever we decide on, we need to check that we're
getting this right and doing it consistently across our pages.

jmc



Re: Add note about example dhclient.conf

2020-02-08 Thread Jason McIntyre
On Sat, Feb 08, 2020 at 01:37:00PM -0800, Kyle Isom wrote:
> On Fri, Feb 7, 2020, at 23:22, Jason McIntyre wrote:
> > if we do reference these config files from the man pages, i guess that
> > should be correctly done from a FILES section, since EXAMPLES is really
> > showing how to use the tool, rather than how to configure it. it is a
> > fine line though.
> > 
> > i wouldn;t be against adding to FILES - it'd be very brief, make sense,
> > and provide the reminder being asked for.
> 
> I got the EXAMPLES part from httpd.conf(5). If you think the note should 
> still be added there, I'm happy to do that. In the case where following the 
> style of httpd.conf(5) is okay, here's an updated diff, though it's hard to 
> tell from this thread if it's wanted.
> 
> 
> - kyle
> 
> 
> Index: sbin/dhclient/dhclient.conf.5
> ===
> RCS file: /cvs/src/sbin/dhclient/dhclient.conf.5,v
> retrieving revision 1.49
> diff -u -p -u -p -r1.49 dhclient.conf.5
> --- sbin/dhclient/dhclient.conf.5 17 Dec 2019 14:21:54 -  1.49
> +++ sbin/dhclient/dhclient.conf.5 8 Feb 2020 21:31:05 -
> @@ -288,6 +288,11 @@ instead of the
>  .Ic sname
>  field of the DHCP offer when binding a lease.
>  .El
> +.Sh EXAMPLES
> +An example configuration for
> +.Pa dhclient.conf
> +is provided in
> +.Pa /etc/examples/dhclient.conf .
>  .Sh SEE ALSO
>  .Xr dhclient.leases 5 ,
>  .Xr dhcp-options 5 ,
> 

in my opinion, i'm definitely against this type of addition: it adds an
EXAMPLES section, without providing any examples.

- i'm ok with adding the path to these files to a FILES section
- i'm ok with afterboot.8 mentioning /etc/examples
- i recognise that there may be some cases where EXAMPLES points to the
  example config. it possibly makes sense for httpd.conf. i don;t think
  it makes sense for dhclient.conf.

jmc



get rid of almost empty /etc/examples/mixerctl.conf

2020-02-08 Thread Ingo Schwarze
Hi Theo,

you have a point, that was a lot of cheap talk and no patch.

I don't aim at changing yacc(1) grammars.  I think most parts of
OpenBSD configuration systems already have sane defaults and most
configuration syntaxes are already good with respect to simplicity
and usability.  At least "most", maybe even all.

> The example files were moved from /etc, so that /etc contained fewer
> files for unconfigured software.

That was a very good step, and it was also good to not encumber it
by trying to do more at the same time.

> Little to no effort was put into curating them.  That's the gap that
> occured.

So, here i'm putting a few pennies where my mouth is, starting from the
shortest file in /etc/examples/.  The example is so short that cut and
paste from the manual page will certainly cause no trouble, and the
file also isn't a special case with respect to permissions,
it is -rw-r--r-- root:wheel.

OK?
  Ingo


P.S.
When preparing this, i noticed i already had the change to
mixerctl.conf.5 in my tree.  It looks like i started it
in the past, then forgot about it.

P.P.S.
Note that i will not propose to get rid of *all* of /etc/examples/,
but just of trivial examples that provide no benefit by being outside
the manual page.  There are certainly some that make sense as they
are.


Index: etc/Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.477
diff -u -p -r1.477 Makefile
--- etc/Makefile24 Jan 2020 06:17:37 -  1.477
+++ etc/Makefile8 Feb 2020 21:42:14 -
@@ -46,7 +46,7 @@ MUTABLE=changelist daily etc.${MACHINE}/
 
 # -rw-r--r--
 EXAMPLES=acme-client.conf chio.conf dhclient.conf dhcpd.conf exports \
-   httpd.conf ifstated.conf inetd.conf man.conf mixerctl.conf \
+   httpd.conf ifstated.conf inetd.conf man.conf \
mrouted.conf ntpd.conf printcap rad.conf rbootd.conf \
remote sensorsd.conf wsconsctl.conf
 
Index: share/man/man5/mixerctl.conf.5
===
RCS file: /cvs/src/share/man/man5/mixerctl.conf.5,v
retrieving revision 1.7
diff -u -p -r1.7 mixerctl.conf.5
--- share/man/man5/mixerctl.conf.5  30 Jul 2018 17:24:24 -  1.7
+++ share/man/man5/mixerctl.conf.5  8 Feb 2020 21:42:14 -
@@ -141,6 +141,11 @@ Default audio mixing device.
 .Xr mixerctl 1
 configuration file.
 .El
+.Sh EXAMPLES
+Most audio cards support setting the output volume by adding this line to
+.Nm :
+.Pp
+.Dl outputs.master=200
 .Sh SEE ALSO
 .Xr aucat 1 ,
 .Xr audioctl 1 ,
Index: etc/examples/mixerctl.conf
===
RCS file: etc/examples/mixerctl.conf
diff -N etc/examples/mixerctl.conf
--- etc/examples/mixerctl.conf  16 Jul 2014 13:21:33 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,7 +0,0 @@
-# $OpenBSD: mixerctl.conf,v 1.1 2014/07/16 13:21:33 deraadt Exp $
-#
-# mixerctl(1) configurable parameters. See mixerctl.conf(5) for details.
-#
-
-# output volume value for most audio cards
-#outputs.master=200



Re: Add note about example dhclient.conf

2020-02-08 Thread Kyle Isom
On Fri, Feb 7, 2020, at 23:22, Jason McIntyre wrote:
> if we do reference these config files from the man pages, i guess that
> should be correctly done from a FILES section, since EXAMPLES is really
> showing how to use the tool, rather than how to configure it. it is a
> fine line though.
> 
> i wouldn;t be against adding to FILES - it'd be very brief, make sense,
> and provide the reminder being asked for.

I got the EXAMPLES part from httpd.conf(5). If you think the note should still 
be added there, I'm happy to do that. In the case where following the style of 
httpd.conf(5) is okay, here's an updated diff, though it's hard to tell from 
this thread if it's wanted.


- kyle


Index: sbin/dhclient/dhclient.conf.5
===
RCS file: /cvs/src/sbin/dhclient/dhclient.conf.5,v
retrieving revision 1.49
diff -u -p -u -p -r1.49 dhclient.conf.5
--- sbin/dhclient/dhclient.conf.5   17 Dec 2019 14:21:54 -  1.49
+++ sbin/dhclient/dhclient.conf.5   8 Feb 2020 21:31:05 -
@@ -288,6 +288,11 @@ instead of the
 .Ic sname
 field of the DHCP offer when binding a lease.
 .El
+.Sh EXAMPLES
+An example configuration for
+.Pa dhclient.conf
+is provided in
+.Pa /etc/examples/dhclient.conf .
 .Sh SEE ALSO
 .Xr dhclient.leases 5 ,
 .Xr dhcp-options 5 ,



Re: lcd(4/hppa): timeout_add(9) -> timeout_add_usec(9)

2020-02-08 Thread Scott Cheloha
On Sun, Dec 22, 2019 at 01:17:56PM -0600, Scott Cheloha wrote:
> lcd_softc.sc_delay's unit appears to be microseconds.
> 
> ok?

1 month bump.

Index: dev/lcd.c
===
RCS file: /cvs/src/sys/arch/hppa/dev/lcd.c,v
retrieving revision 1.4
diff -u -p -r1.4 lcd.c
--- dev/lcd.c   11 Dec 2015 16:07:01 -  1.4
+++ dev/lcd.c   8 Feb 2020 19:14:08 -
@@ -138,7 +138,7 @@ lcd_blink(void *v, int on)
 
sc->sc_on = on;
bus_space_write_1(sc->sc_iot, sc->sc_cmdh, 0, sc->sc_heartbeat[0]);
-   timeout_add(>sc_to, max(1, (sc->sc_delay * hz) / 100));
+   timeout_add_usec(>sc_to, sc->sc_delay);
 }
 
 void



Re: Add note about example dhclient.conf

2020-02-08 Thread su.root
On 08/02   17:33, Ingo Schwarze wrote:

I have no idea what your target audience is and what (if any) your
mission staement is. Assumptions
are being made pertaining to the end user skill set and this is already
a slippery slope.

> Hi,
> 
> i think i said it before:  i hate /etc/examples/ and think that the
> directory ought to be mostly empty.  With the exception of rare
> cases like bgpd(8), where you have to provide a lot of information
> before you can start it in any meaningful way, i consider a deamon
> ill-designed if the configuration is so complicated that a file in
> /etc/examples/ serves any purpose.  Daemons should have a reasonable
> default configuration, such that a configuration file is not needed
> for typical usage, and if people add a configuration file, they
> ought to get away with very few lines.  By the way, acme-client(1)
> is an example where i was happy to recently see people work into just
> that direction.
> 
> Providing example configuration files is an idiotic concept because
> if you copy them into /etc/, you no longer easily see what the
> defaults are, what generic recommendations are, and what was changed
> locally.  It should be made easy to write short configuration files
> from scratch such that they contain absolutely nothing except local
> changes.
> 
> For daemons designed as described, if they have some complicated
> configuration commands for special purposes, a few typical
> examples of these commands can be shown in the EXAMPLES section of
> the manual page.
> 
> Note that in the past, there was no consensus about the above, so
> i'm not suggesting that we move all the examples into the manual
> pages.  I'm only saying *trivial* files in /etc/examples/ should
> be deleted and the content, if any, moved to the manual pages.  Some
> files will no doubt remain, and there is nothing wrong with that.
> 
> Jason McIntyre wrote on Sat, Feb 08, 2020 at 07:22:06AM +:
> 
> > if we do reference these config files from the man pages, i guess that
> > should be correctly done from a FILES section, since EXAMPLES is really
> > showing how to use the tool, rather than how to configure it. it is a
> > fine line though.
> > 
> > i wouldn;t be against adding to FILES - it'd be very brief, make sense,
> > and provide the reminder being asked for.
> 
> I like that very much, yes.  In general, if there is a file closely
> related to the content of the manual page, mention it below FILES.
> That also seems like a good idea for files below /etc/examples/.
> 
> Yours,
>   Ingo
> 



Re: Add note about example dhclient.conf

2020-02-08 Thread Theo de Raadt
Ingo Schwarze  wrote:

> Hi,
> 
> i think i said it before:  i hate /etc/examples/ and think that the
> directory ought to be mostly empty.

We'll get to that.

  With the exception of rare
> cases like bgpd(8), where you have to provide a lot of information
> before you can start it in any meaningful way, i consider a deamon
> ill-designed if the configuration is so complicated that a file in
> /etc/examples/ serves any purpose.  Daemons should have a reasonable
> default configuration, such that a configuration file is not needed
> for typical usage, and if people add a configuration file, they
> ought to get away with very few lines.  By the way, acme-client(1)
> is an example where i was happy to recently see people work into just
> that direction.

reading between the lines, I think you recognize the difficulty in
changing grammer. the acme-client thing was a good step, but enough
-current users already failed their key rotations, that we can tell
there will be challenges when 6.7 is shipped.  I am certain you aren't
proposing we change a yacc tomorrow.

> Providing example configuration files is an idiotic concept because
> if you copy them into /etc/, you no longer easily see what the
> defaults are, what generic recommendations are, and what was changed
> locally.  It should be made easy to write short configuration files
> from scratch such that they contain absolutely nothing except local
> changes.

But then you take another shot at it.  "It should be made easy".
Your email lacks proposed changes to any .y files.

> For daemons designed as described, if they have some complicated
> configuration commands for special purposes, a few typical
> examples of these commands can be shown in the EXAMPLES section of
> the manual page.

And then, for many configuration files, you can't simply cut-and-paste,
because there's an indent to the line you need to remove, and additional
long lines could be improper, and tabs turned into spaces.

Awesome, except it isn't.

> Note that in the past, there was no consensus about the above, so
> i'm not suggesting that we move all the examples into the manual
> pages.  I'm only saying *trivial* files in /etc/examples/ should
> be deleted and the content, if any, moved to the manual pages.  Some
> files will no doubt remain, and there is nothing wrong with that.

Let's step back.

The example files were moved from /etc, so that /etc contained fewer
files for unconfigured software.

Little to no effort was put into curating them.  That's the gap that
occured.

But then you start talking about removing files, changing configuration
languages, and deck-chair shuffling into manual pages as if it can be
done simply and will always result in an improvement.

I am reading a large action plan full of generic suggestions without
any specifics.



Re: Add note about example dhclient.conf

2020-02-08 Thread Antoine Jacoutot
On Sat, Feb 08, 2020 at 05:33:34PM +0100, Ingo Schwarze wrote:
> Hi,
> 
> i think i said it before:  i hate /etc/examples/ and think that the
> directory ought to be mostly empty.  With the exception of rare
> cases like bgpd(8), where you have to provide a lot of information
> before you can start it in any meaningful way, i consider a deamon
> ill-designed if the configuration is so complicated that a file in
> /etc/examples/ serves any purpose.  Daemons should have a reasonable
> default configuration, such that a configuration file is not needed
> for typical usage, and if people add a configuration file, they
> ought to get away with very few lines.  By the way, acme-client(1)
> is an example where i was happy to recently see people work into just
> that direction.
> 
> Providing example configuration files is an idiotic concept because
> if you copy them into /etc/, you no longer easily see what the
> defaults are, what generic recommendations are, and what was changed
> locally.  It should be made easy to write short configuration files
> from scratch such that they contain absolutely nothing except local
> changes.
> 
> For daemons designed as described, if they have some complicated
> configuration commands for special purposes, a few typical
> examples of these commands can be shown in the EXAMPLES section of
> the manual page.
> 
> Note that in the past, there was no consensus about the above, so
> i'm not suggesting that we move all the examples into the manual
> pages.  I'm only saying *trivial* files in /etc/examples/ should
> be deleted and the content, if any, moved to the manual pages.  Some
> files will no doubt remain, and there is nothing wrong with that.

Agreed.

-- 
Antoine



Remove non-__STDC__ asserts from

2020-02-08 Thread Visa Hankala
The header  defines two sets of assert macros,
one for standard C and another for the traditional cpp. As the header
requires the use of a C compiler (that is, no inclusion from an assembly
file), it looks that the non-__STDC__ parts could be removed.

OK?

Index: lib/libkern/libkern.h
===
RCS file: src/sys/lib/libkern/libkern.h,v
retrieving revision 1.35
diff -u -p -r1.35 libkern.h
--- lib/libkern/libkern.h   25 Apr 2018 11:15:58 -  1.35
+++ lib/libkern/libkern.h   8 Feb 2020 16:41:00 -
@@ -105,13 +105,8 @@ abs(int j)
 #ifdef NDEBUG  /* tradition! */
 #defineassert(e)   ((void)0)
 #else
-#ifdef __STDC__
 #defineassert(e)   ((e) ? (void)0 :
\
__assert("", __FILE__, __LINE__, #e))
-#else
-#defineassert(e)   ((e) ? (void)0 :
\
-   __assert("", __FILE__, __LINE__, "e"))
-#endif
 #endif
 
 #define__KASSERTSTR"kernel %sassertion \"%s\" failed: file \"%s\", 
line %d"
@@ -120,38 +115,22 @@ abs(int j)
 #defineKASSERTMSG(e, msg, ...) ((void)0)
 #defineKASSERT(e)  ((void)0)
 #else
-#ifdef __STDC__
 #defineKASSERTMSG(e, msg, ...) ((e) ? (void)0 :
\
panic(__KASSERTSTR " " msg, "diagnostic ", #e,  \
__FILE__, __LINE__, ## __VA_ARGS__))
 #defineKASSERT(e)  ((e) ? (void)0 :
\
__assert("diagnostic ", __FILE__, __LINE__, #e))
-#else
-#defineKASSERTMSG(e, msg, ...) ((e) ? (void)0 :
\
-   panic(__KASSERTSTR " " msg, "diagnostic ", "e", \
-   __FILE__, __LINE__, ## __VA_ARGS__))
-#defineKASSERT(e)  ((e) ? (void)0 :
\
-   __assert("diagnostic ", __FILE__, __LINE__, "e"))
-#endif
 #endif
 
 #ifndef DEBUG
 #defineKDASSERTMSG(e, msg, ...)((void)0)
 #defineKDASSERT(e) ((void)0)
 #else
-#ifdef __STDC__
 #defineKDASSERTMSG(e, msg, ...)((e) ? (void)0 :
\
panic(__KASSERTSTR " " msg, "debugging ", #e,   \
__FILE__, __LINE__, ## __VA_ARGS__))
 #defineKDASSERT(e) ((e) ? (void)0 :
\
__assert("debugging ", __FILE__, __LINE__, #e))
-#else
-#defineKDASSERTMSG(e, msg, ...)((e) ? (void)0 :
\
-   panic(__KASSERTSTR " " msg, "debugging ", "e",  \
-   __FILE__, __LINE__, ## __VA_ARGS__))
-#defineKDASSERT(e) ((e) ? (void)0 :
\
-   __assert("debugging ", __FILE__, __LINE__, "e"))
-#endif
 #endif
 
 #defineCTASSERT(x) extern char  _ctassert[(x) ? 1 : -1 ]   \



Zero knotes on allocation

2020-02-08 Thread Visa Hankala
Zero knotes on allocation. Parts of struct knote, such as kn_tqe, can
retain their old value quite long, which is not good in this complex
piece of code.

OK?

Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.122
diff -u -p -r1.122 kern_event.c
--- kern/kern_event.c   5 Feb 2020 17:03:13 -   1.122
+++ kern/kern_event.c   8 Feb 2020 16:41:00 -
@@ -686,7 +686,7 @@ kqueue_register(struct kqueue *kq, struc
}
 
if (kev->flags & EV_ADD)
-   newkn = pool_get(_pool, PR_WAITOK);
+   newkn = pool_get(_pool, PR_WAITOK | PR_ZERO);
 
 again:
if (fops->f_isfd) {



Re: Add note about example dhclient.conf

2020-02-08 Thread Ingo Schwarze
Hi,

i think i said it before:  i hate /etc/examples/ and think that the
directory ought to be mostly empty.  With the exception of rare
cases like bgpd(8), where you have to provide a lot of information
before you can start it in any meaningful way, i consider a deamon
ill-designed if the configuration is so complicated that a file in
/etc/examples/ serves any purpose.  Daemons should have a reasonable
default configuration, such that a configuration file is not needed
for typical usage, and if people add a configuration file, they
ought to get away with very few lines.  By the way, acme-client(1)
is an example where i was happy to recently see people work into just
that direction.

Providing example configuration files is an idiotic concept because
if you copy them into /etc/, you no longer easily see what the
defaults are, what generic recommendations are, and what was changed
locally.  It should be made easy to write short configuration files
from scratch such that they contain absolutely nothing except local
changes.

For daemons designed as described, if they have some complicated
configuration commands for special purposes, a few typical
examples of these commands can be shown in the EXAMPLES section of
the manual page.

Note that in the past, there was no consensus about the above, so
i'm not suggesting that we move all the examples into the manual
pages.  I'm only saying *trivial* files in /etc/examples/ should
be deleted and the content, if any, moved to the manual pages.  Some
files will no doubt remain, and there is nothing wrong with that.

Jason McIntyre wrote on Sat, Feb 08, 2020 at 07:22:06AM +:

> if we do reference these config files from the man pages, i guess that
> should be correctly done from a FILES section, since EXAMPLES is really
> showing how to use the tool, rather than how to configure it. it is a
> fine line though.
> 
> i wouldn;t be against adding to FILES - it'd be very brief, make sense,
> and provide the reminder being asked for.

I like that very much, yes.  In general, if there is a file closely
related to the content of the manual page, mention it below FILES.
That also seems like a good idea for files below /etc/examples/.

Yours,
  Ingo



Re: iwm: work around missing Tx completion interrupts

2020-02-08 Thread Tobias Heider
On Thu, Feb 06, 2020 at 12:45:38PM +0100, Stefan Sperling wrote:
> At 36c3 I noticed roaming failures with iwm(4) where we would get stuck
> trying to roam to a different AP. Debugging this with bluhm@ we found
> that the reason it gets stuck is a non-zero refcount on the ic_bss node.
> 
> When roaming, we wait for this reference count to hit zero before switching
> the new AP. A non-zero reference count implies that the driver still has
> outstanding frames destined for the old AP queued to hardware.
> What we observed was that the reference count never went back to zero
> so roaming never completed and no further data frames could be sent.
> ifconfig iwm0 down/up was required to get the interface working again.
> 
> iwm(4) decrements the refcount whenever hardware signals Tx completion
> for a frame at Tx queue index 'N'. We observed that we sometimes get an
> interrupt for frame 'N - 2' followed by an interrupt for frame 'N',
> with no interrupt being received for frame 'N - 1'.
> Whenever this had occurred a later decision to roam to another AP would
> fail as described above. A side-effect of this is that an mbuf gets leaked.
> 
> This diff implements a workaround in iwm's interrupt handler.
> It's not pretty but I don't know the root cause.
> Given that this happens very rarely, and all we lose is success/failure
> information for the affected frames, this workaround seems acceptable to me.
> 
> So far I only managed to trigger the problem at 36c3.
> If you want to see a printf when it happens, compile with 'option IWM_DEBUG'.
> 
> ok?

I've been testing the diff for the last two days and haven't seen any
regressions. Unfortunately it seems I also didn't manage to trigger the
actual bug so I can not say for sure whether your workaround actually
fixes it. 

I think your solution makes sense until we found the underlying problem.



Re: Push KERNEL_LOCK() down in pgsigio() and selwakeup()

2020-02-08 Thread Visa Hankala
On Tue, Feb 04, 2020 at 02:21:02PM +0100, Martin Pieuchot wrote:
> As recently profiled, the softnet thread which runs mostly without
> KERNEL_LOCK() is still somehow serialized with the rest of the kernel.
> This is because the various subsystems to notify userland, either via
> poll(2)/select(2), kqueue(2) or pgsignal(9) still require this lock. 
> 
> We worked around this in bpf(4) by deferring the notification.  However
> such approach isn't trivially applied everywhere and doesn't help with
> getting the subsystems out of the KERNEL_LOCK().
> 
> Thanks to many people working on MP, the kernel now has multiple consumers
> of the notification hooks that can be used to test & expose possible bugs
> related to the removal of the KERNEL_LOCK() in these areas.
> 
> Diff below takes the first step of pushing the KERNEL_LOCK() in the
> subsystems.  That means the lock might be taken & released twice if an
> application asked for being notified via signal and via poll/kevent.

I think this is fine. Use of signal-based notification is quite unusual
in modern software, and use of both signals and poll/kevent with the same
file is all the more so.

> It is unclear to me if this change of behavior degrades latency in a 
> noticeable way.  If it does and people report it, we should consider
> keeping a single KERNEL_LOCK/UNLOCK() dance in the affected subsystem.
> 
> Comments?  Oks?

OK visa@



Re: Add note about example dhclient.conf

2020-02-08 Thread su.root
May be a notation in the afterboot man page. Users generally stumble across 
/etc/examples by pure luck and after considerable time.

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Jason McIntyre
Sent: Saturday, 8 February 2020 08:24
To: tech@openbsd.org
Subject: Re: Add note about example dhclient.conf

On Fri, Feb 07, 2020 at 08:46:05PM -0700, Aaron Bieber wrote:
> On Fri, 07 Feb 2020 at 17:49:41 -0800, Kyle Isom wrote:
> > I was looking through the dhclient.conf man page and missed that there was 
> > an example config in /etc/examples, so I added this to the man page. I'm 
> > also happy to go through the rest of man pages for the examples and add 
> > them if there's interest.
> > 
> > Cheers,
> > Kyle
> > 
> > 
> > Index: sbin/dhclient/dhclient.conf.5
> > ===
> > RCS file: /cvs/src/sbin/dhclient/dhclient.conf.5,v
> > retrieving revision 1.49
> > diff -u -p -u -p -r1.49 dhclient.conf.5
> > --- sbin/dhclient/dhclient.conf.5   17 Dec 2019 14:21:54 -  1.49
> > +++ sbin/dhclient/dhclient.conf.5   8 Feb 2020 00:22:38 -
> > @@ -288,6 +288,11 @@ instead of the
> > .Ic sname
> > field of the DHCP offer when binding a lease.
> > .El
> > +.Sh EXAMPLE
> > +There is an example
> > +.Pa dhclient.conf
> > +in
> > +.Pa /etc/examples/dhclient.conf .
> > .Sh SEE ALSO
> > .Xr dhclient.leases 5 ,
> > .Xr dhcp-options 5 ,
> > 
> 
> IMO this is worth doing. acme-client.1 and httpd.conf.5 have reference to
> /etc/examples, and I have run into a number of people that are unaware of the
> existence of the examples.
> 
> Maybe something a bit more similar to what's in acme-client(1) which uses a
> more standard EXAMPLES section:
> 
> .Sh EXAMPLES
> Example configuration files for
> .Nm
> and
> .Xr httpd 8
> are provided in
> .Pa /etc/examples/acme-client.conf
> 
> I talked with tj@ about this as well, he suggested another route would be to
> add full examples in the lacking pages. IMO both approaches would probably be
> beneficial but I think directing more attention to /etc/examples is a good
> start.
> 
> Anyone else have any thoughts?
> 

hi.

i forget the logic, but i think the aim was to have a potential config
somewhere helpful, without clogging the man pages. to that end, i'm not
sure it'd make sense to effectively move the files back into the man
pages.

the best thing is probably for everyone to know there is such a thing as
/etc/examples. i accept that's maybe unlikely.

if we do reference these config files from the man pages, i guess that
should be correctly done from a FILES section, since EXAMPLES is really
showing how to use the tool, rather than how to configure it. it is a
fine line though.

i wouldn;t be against adding to FILES - it'd be very brief, make sense,
and provide the reminder being asked for.

jmc