Re: CVS commit: src/etc/rc.d

[Martin Husemann]

On Sun, Jun 11, 2023 at 11:23:23AM +0300, Kimmo Suominen wrote:
> My thinking here is that it makes it simpler to keep the script in
> sync between branches. (I have not checked, but I guess the sysctl
> does not depend on kernel configuration then.)

In this special case I think this would not be a good idea as the
entropy changes between current and 10 vs. -9 are fundamental and
heavily disputed.

Keeping things minimal, clean and consistent is IMO preferable here.

Martin

Re: CVS commit: src/etc/rc.d

[Kimmo Suominen]

On Sat, 10 Jun 2023 at 20:08, Martin Husemann  wrote:
> I don't like this commit, it mixes:
>
>  - several text improvements (good!)
>  - one unrelated cosmetic change (rely on all rc.d scripts being installed
>with x bit, so drop the "sh" from the manual invocation)

Calling the rc.d script directly is how we teach people to do it in
the NetBSD Guide:
https://www.netbsd.org/docs/guide/en/chap-rc.html#chap-rc-scripts

The usage message that rc.d scripts produce also shows executing them directly:

# service sshd check
/etc/rc.d/sshd: unknown directive 'check'.
Usage: /etc/rc.d/sshd [fast|force|one](start stop restart rcvar
keygen reload status poll)

I think adopting a single convention across the board would be least
confusing for users.

Personally I like calling rc.d scripts using service(8) as it makes an
effort to run the rc.d script as close as possible to how it is run
from rc(8). I find setting the current working directory to / is
especially prudent and noteworthy.

However, it would appear that service(8) has a bug where it also
relies on executing the rc.d script directly. In practise it would be
rare to run into it, though, as we do seem to install rc.d scripts
with all the execute bits set. The error service(8) outputs when no
execute bits are set is "sshd does not exist in /etc/rc.d," which can
be perplexing when /etc/rc.d/sshd clearly does exist.

>  - one unrelated and IMO unneded change (check if kern.entropy.needed
>exists, only usefull for older branches)

My thinking here is that it makes it simpler to keep the script in
sync between branches. (I have not checked, but I guess the sysctl
does not depend on kernel configuration then.)

Kind regards,
+ Kimmo

Re: CVS commit: src/etc/rc.d

[Martin Husemann]

On Sat, Jun 10, 2023 at 04:02:39AM +, Kimmo Suominen wrote:
> Module Name:  src
> Committed By: kim
> Date: Sat Jun 10 04:02:39 UTC 2023
> 
> Modified Files:
>   src/etc/rc.d: sshd
> 
> Log Message:
> Add some backwards compat.  Adjust grammar.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.35 -r1.36 src/etc/rc.d/sshd

I don't like this commit, it mixes:

 - several text improvements (good!)
 - one unrelated cosmetic change (rely on all rc.d scripts being installed
   with x bit, so drop the "sh" from the manual invocation)
 - one unrelated and IMO unneded change (check if kern.entropy.needed
   exists, only usefull for older branches)

Martin

Re: CVS commit: src/etc

[Christos Zoulas]

In article <20221128024658.71caaf...@cvs.netbsd.org>,
Jan Schaumann  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  jschauma
>Date:  Mon Nov 28 02:46:58 UTC 2022
>
>Modified Files:
>   src/etc: protocols
>
>Log Message:
>regen from IANA 2022-09-28
>
>
>To generate a diff of this commit:
>cvs rdiff -u -r1.31 -r1.32 src/etc/protocols
>
>Please note that diffs are not public domain; they are subject to the
>copyright notices on the relevant files.
>
>
>-=-=-=-=-=-
>
>Modified files:
>
>Index: src/etc/protocols
>diff -u src/etc/protocols:1.31 src/etc/protocols:1.32
>--- src/etc/protocols:1.31 Thu Apr  8 19:03:43 2021
>+++ src/etc/protocols  Mon Nov 28 02:46:58 2022
>@@ -1,8 +1,10 @@
>-# $NetBSD: protocols,v 1.31 2021/04/08 19:03:43 christos Exp $
>-# See also: protocols(5), http://www.sethwklein.net/projects/iana-etc/
>+# $NetBSD: protocols,v 1.32 2022/11/28 02:46:58 jschauma Exp $
>+# See also: protocols(5), https://www.iana.org/assignments/protocol-numbers/
> #
>+#   
>Protocol Numbers
>+# 
> #Last Updated
>-#2021-02-26
>+#2022-09-28
> # 
> #Available Formats
> #[IMG]
>@@ -50,7 +52,7 @@ igmp   2 IGMP # Internet
> ggp3 GGP  # Gateway-to-Gateway 
>[RFC823]
> ipv4   4 IPv4 # IPv4 encapsulation 
>[RFC2003]
> st 5 ST   # Stream 
>[RFC1190][RFC1819]
>-tcp6 TCP  # Transmission Control   
>[RFC793]
>+tcp6 TCP  # Transmission Control   
>[RFC9293]
> cbt7 CBT  # CBT
>[Tony_Ballardie]
> egp8 EGP  # Exterior Gateway Protocol  
>[RFC888][David_Mills]
> #   any private interior gateway
>@@ -162,9 +164,9 @@ iso-ip80 ISO-IP   # ISO Inte
> vmtp  81 VMTP # VMTP   
>[Dave_Cheriton]
> secure-vmtp   82 SECURE-VMTP  # SECURE-VMTP
>[Dave_Cheriton]
> vines 83 VINES# VINES  
>[Brian Horn]
>-ttp   84 TTP iptm IPTM # Transaction Transport 
>[Jim_Stevens]
>+ttp   84 TTP  # Transaction Transport  
>[Jim_Stevens]
> #   Protocol
>-#iptm  84 IPTM # Internet Protocol Traffic 
>[Jim_Stevens]
>+iptm  84 IPTM # Internet Protocol Traffic  

This will probably make the test fail. It was manually handled before
[the alias to the same number]

>[Jim_Stevens]
> #   Manager
> nsfnet-igp85 NSFNET-IGP   # NSFNET-IGP 
>[Hans_Werner_Braun]
> dgp   86 DGP  # Dissimilar Gateway Protocol
>[M/A-COM Government Systems, "Dissimilar Gateway Protocol
>Specification,
>@@ -205,7 +207,7 @@ ipcomp   108 IPComp   # IP Paylo
> snp  109 SNP  # Sitara Networks Protocol   
>[Manickam_R_Sridhar]
> compaq-peer  110 Compaq-Peer  # Compaq Peer Protocol   
>[Victor_Volpe]
> ipx-in-ip111 IPX-in-IP# IPX in IP  
>[CJ_Lee]
>-vrrp 112 VRRP carp# Virtual Router Redundancy  
>[RFC5798]
>+vrrp 112 VRRP # Virtual Router Redundancy  
>[RFC5798]
> #   Protocol
> pgm  113 PGM  # PGM Reliable Transport 
>[Tony_Speakman]
> #   Protocol
>@@ -238,16 +240,16 @@ rsvp-e2e-ignore 134 RSVP-E2E-IGNORE # [R
> mobility 135 Mobility # Header 
>Y[RFC6275]
> udplite  136 UDPLite  # [RFC3828]
> mpls-in-ip   137 MPLS-in-IP   # [RFC4023]
>-manet138 MANET# MANET Protocols
>[RFC5498]
>+manet138 manet# MANET Protocols

This will also probably make the test fail (alias to the same name)

>[RFC5498]
> hip  139 HIP  # Host Identity Protocol Y   
>[RFC7401]
> shim6140 Shim6# Shim6 Protocol Y   
>[RFC5533]
> wesp 141 WESP # Wrapped Encapsulating  
>[RFC5840]
> #   Security Payload
> rohc 142 ROHC # Robust Header Compression  
>[RFC5858]
> ethernet 143 Ethernet # Ethernet   
>[RFC8986]
>-#144-252Unassigned 
>[Internet_Assigned_Numbers_Authority]
>-pfsync   240 PFSYNC   # PF Synchronization

I would put this back, it is unofficial, but used.

christos

Re: CVS commit: src/etc/rc.d

[Luke Mewburn]

On 22-08-24 20:39, Robert Elz wrote:
  | Date:Wed, 24 Aug 2022 20:37:54 +1000
  | From:Luke Mewburn 
  | Message-ID:  
  | 
  |   | I think it would be more consistent with existing convention
  |   | (in both NetBSD and on other systems) to add /etc/raid.d
  | 
  | I certainly won't be doing that, I detest the ".d" convention
  | as a general thing.   I personally prefer /etc/conf for config
  | files (I use it for all kinds of things) which then don't need
  | redundant ".conf" noise in their names (I have never much liked
  | the concept of filename extensions at all).

So you've changed the system for your personal preference versus
existing conventions.

Are we going to see lots of other local changes to the system
for this /etc/conf directory, without at least some discussion
and consensus?


  | Note I didn't add the directory, for most people (who don't just
  | use raid autoconfig - at the minute I have reasons for not doing
  | that) can keep using the files that have always been used.  To
  | use /etc/conf/raid you have to go manually set it up for yourself.

That's a silver lining I suppose :)

  
  | If you want to add some other place where the files could be put,
  | by all means, go ahead.

Well, if I was to, I'd be suggesting /etc/raid.d/*.conf just to follow
existing practice within the system.


  | kre
  | 
  | ps: that all happened over a month ago...

That doesn't invalidate my feedback; not all of us can keep up with
every change in real time.

Re: CVS commit: src/etc/rc.d

[Robert Elz]

Date:Wed, 24 Aug 2022 20:37:54 +1000
From:Luke Mewburn 
Message-ID:  

  | I think it would be more consistent with existing convention
  | (in both NetBSD and on other systems) to add /etc/raid.d

I certainly won't be doing that, I detest the ".d" convention
as a general thing.   I personally prefer /etc/conf for config
files (I use it for all kinds of things) which then don't need
redundant ".conf" noise in their names (I have never much liked
the concept of filename extensions at all).

Note I didn't add the directory, for most people (who don't just
use raid autoconfig - at the minute I have reasons for not doing
that) can keep using the files that have always been used.  To
use /etc/conf/raid you have to go manually set it up for yourself.

If you want to add some other place where the files could be put,
by all means, go ahead.

kre

ps: that all happened over a month ago...

Re: CVS commit: src/etc/rc.d

[Luke Mewburn]

On 22-07-21 07:49, Robert Elz wrote:
  | Module Name:src
  | Committed By:   kre
  | Date:   Thu Jul 21 07:49:36 UTC 2022
  | 
  | Modified Files:
  | src/etc/rc.d: raidframe
  | 
  | Log Message:
  | Make this better ...   Allow config file for raidN to be found
  | in /etc/conf/raid/raidN (as well as in /etc/raidN.conf) (less
  | clutter in /etc).

I think it would be more consistent with existing convention
(in both NetBSD and on other systems) to add /etc/raid.d and use
/etc/raid.d/raidN
or even
/etc/raid.d/raidN.conf
instead of adding a new /etc/conf/ directory and using
/etc/conf/raid/raidN


  | To generate a diff of this commit:
  | cvs rdiff -u -r1.11 -r1.12 src/etc/rc.d/raidframe



Luke.

Re: CVS commit: src/etc

[Simon Burge]

Hi Alex,

Alexander Nasonov wrote:

> Simon Burge wrote:
> > Why don't we just mount all the ZFS filesystems in mountcritlocal?
>
> Future versions may require loading of encryption keys over kerberos
> or a special pam module to decrypt /home/$USER.

How is this different to the existing "zfs mount -a" that
/etc/rc.d/mountall does?  Would there be new rc.d scripts between
mountcritlocal and mountall ?

Cheers,
Simon.

Re: CVS commit: src/etc

[Brad Spencer]

Greg Troxel  writes:

[snip]

>
>   I am opposed to deciding that all zfs filesystems should be treated as
>   critical (in a world where we have not abolished the notion).
>
>   We could have a discussion about why we even have the concept of
>   critical filesystems, but if so that should not be about zfs and
>   should be in a new thread on tech-userlevel.  And, I think it really
>   isn't strongly releated to this discussion.

[snip]

Ya, I suspect that the notion of precedence needs to be developed
somehow and not abuse the notion of critical too much.  That is,
filesystem mounting by type needs to happen in a particular order.  The
default would have to choose something, either making not ZFS happen
first followed by normal and usual ZFS pools, or the other way around.
I suspect that someone loses out as no default can handle every way that
ZFS may be used when other filesystem types are present.  For example,
in the cases I have, a FFS is the root filesystem along with other FFS
file systems.  Under these are ZFS normal pools, so the order I would
prefer in this case is mount FFS first and then import the pools, as the
places that the pools would mount under would not exist the other way
around.  However, I very much understand that the other way around could
exist where ZFS normal pools are imported before anything else.  I
honestly don't remember what Solaris did, but I can't see any ordering
default with NetBSD handling every case in the correct manor.  Even if
it were possible to know the root filesystem type in a simple manor like
one can know the root filesystem device and partition, I don't think
that it would be possible to guess all of the cases correctly.


-- 
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

Re: CVS commit: src/etc

[Greg Troxel]

Brad Spencer  writes:

> What is referred to here is a specific ZFS idea and should not be
> confused with any sort of global notion.  Specifically, ZFS, by default
> and in common use, does not use anything like a /etc/fstab or
> /etc/vfstab to specify where the filesets get mounted.  It also does not
> usually use the usual mount command either to mount them, although that
> would work in Solaris if I remember correctly (at least in some cases).
> What happens is that the mount point is specified in the fileset meta
> data and "zfs mount " takes care of getting it mounted.  If you
> wanted to use /etc/fstab or /etc/vfstab with ZFS you need to mark the
> mountpoint in the fileset as being legacy, then you could fill in your
> /etc/... files as you wanted.  This, of course, strongly suggests that
> Sun was going to make all of the other filesystems except ZFS second
> class, but Sun fell apart before that really progressed to anything
> final and Oracle never really ran to that conclusion either.  No one is

Somehow I am not shocked that this usage (by Sun) had that lurking.

> at all suggesting that any filesystem become second class in the NetBSD
> realization of ZFS.
>
> So the term legacy when speaking of ZFS is used to refer to a filesystem
> that uses whatever /etc/... files you use and uses the usual mount
> command.

Thanks, and Taylor also sent me a clue privately.A superceding
comment by me crossed in the mail.


signature.asc
Description: PGP signature

Re: CVS commit: src/etc

[Greg Troxel]

I apologize for failing to understand "zfs legacy mount" and incorrectly
associating it with how I usually encounter the word legacy.

I now understand that you meant to separate:

  zfs's preferred path of having mountpoints stored as volume
  properties, which is a different way of specifying what is mounted
  where than everything else, but makes sense in a world with many zfs
  volumes

  having a zfs volume where instead of the normal zfs way, there is an
  fstab entry

So having re-thought I would say:

  It makes sense to have a boolean "critical" property (the name you
  suggested is fine) for zfs volumes that specify a mount point, so that
  such volumes would be mounted in mountcritlocal.  I am 100% happy for
  someone to add that and see no big problems.

  It makes sense to just put zfs volume mountpoints in
  critical_filesystems_local, if those volumes use the fstab method
  instead of mountpoint properties (i.e., are "zfs legacy mounts").

  I think this is tricky if there are multiple pools and some don't come
  up.  But I think it's ok if the main path is that one should have all
  critical zfs filesytems on the same pool as root, with root on zfs.
  With root not on zfs but say /usr and /var on zfs, there needs to be
  some way for the boot to fail if they aren't mountable, just like if
  they were in fstab, if the pool doesn't attach and thus the critical
  variable aren't readable.  That might mean "if root is not zfs, and
  something in critical_fileystems_{local,remote} is in zfs, then those
  things have to use zfs legacy mounts".  It might mean having
  "critical_zfs_pools_{local,remote}" which will fail the boot if they
  are not attached at the mountcritlocal/mountcritremote stage, so that
  the critical properties are reliably there.

  I am opposed to deciding that all zfs filesystems should be treated as
  critical (in a world where we have not abolished the notion).

  We could have a discussion about why we even have the concept of
  critical filesystems, but if so that should not be about zfs and
  should be in a new thread on tech-userlevel.  And, I think it really
  isn't strongly releated to this discussion.


for background, I used to understand the critical filesystem scheme
better, but I'll briefly say (projecting to modern rc.d) that I think
it's about sequencing getting enough filesystems mounted to be able to
hit the NETWORKING rc.d barrier.  Consider a diskless workstation with
separate / and /usr (because /usr is shared across all 10 Sun 3/50s :-)
that also needs to mount some other filesystem from a server beyond the
LAN, which requires running routed.  Sorry if that gives yuo bad
flashbacks to the 80s :-)

In modern NetBSD I put /var and /usr in critical_fileystems_local,
because I want route6d to start, and that's in /usr/sbin.  Arguably
route6d should be in /sbin, or NETWORKING should be split into things
needed to talk to the local link vs the broader network, but I have
avoided digging in because adding a line to rc.conf is easy, and moving
route6d would be actual work.

Greg


signature.asc
Description: PGP signature

Re: CVS commit: src/etc

[Brad Spencer]

Greg Troxel  writes:

[snip]

> [I don't really know what you mean by legacy (other than non-zfs, but
> you didn't say that, so perhaps you mean something different).]

[snip]

I am only going to speak to the use of "legacy" in this conversation.

What is referred to here is a specific ZFS idea and should not be
confused with any sort of global notion.  Specifically, ZFS, by default
and in common use, does not use anything like a /etc/fstab or
/etc/vfstab to specify where the filesets get mounted.  It also does not
usually use the usual mount command either to mount them, although that
would work in Solaris if I remember correctly (at least in some cases).
What happens is that the mount point is specified in the fileset meta
data and "zfs mount " takes care of getting it mounted.  If you
wanted to use /etc/fstab or /etc/vfstab with ZFS you need to mark the
mountpoint in the fileset as being legacy, then you could fill in your
/etc/... files as you wanted.  This, of course, strongly suggests that
Sun was going to make all of the other filesystems except ZFS second
class, but Sun fell apart before that really progressed to anything
final and Oracle never really ran to that conclusion either.  No one is
at all suggesting that any filesystem become second class in the NetBSD
realization of ZFS.

So the term legacy when speaking of ZFS is used to refer to a filesystem
that uses whatever /etc/... files you use and uses the usual mount
command.




-- 
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

Re: CVS commit: src/etc

[Alexander Nasonov]

Simon Burge wrote:
> Why don't we just mount all the ZFS filesystems in mountcritlocal?

Future versions may require loading of encryption keys over kerberos
or a special pam module to decrypt /home/$USER.

Alex

Re: CVS commit: src/etc

[Greg Troxel]

Simon Burge  writes:

> I'm running with a complete ZFS-only setup with no legacy mounts.  This
> is my basic ZFS layout (leaving out a few mounts that don't add any more
> value to this discussion):
>
>   NAME  MOUNTPOINT
>   pool0 /pool0
>   pool0/ROOTnone
>   pool0/ROOT/default/
>   pool0/home/home
>   pool0/home/simonb /home/simonb
>   pool0/usr /usr
>   pool0/usr/obj /usr/obj
>   pool0/usr/pkg /usr/pkg
>   pool0/var /var
>   pool0/var/crash   /var/crash
>   pool0/var/log /var/log
>   pool0/var/mail/var/mail
>   pool0/var/tmp /var/tmp
>
> and I then have this grot in my mountcritlocal:
>
>   # XX
>   zfs mount pool0/var
>   zfs mount pool0/var/crash
>   zfs mount pool0/var/log
>   zfs mount pool0/var/mail
>   zfs mount pool0/var/tmp

[I am guessing you have a boot partition that isn't zfs, just to load
the kernel, but I haven't tried to read about that, and it seems a
separate topic.]

I will assume that the / (zfs as you say above) is the only mounted fs
as init starts.

> I have been trying to think of better solutions to this before you added
> this new critical_filesystems_zfs rc.conf variable.  One idea was to add
> a user defined property (eg "netbsd:mountcrit=yes") and use that in a
> similar way to how you implemented mount_critical_filesystems_zfs .  Then
> another idea hit me.
>
> Why don't we just mount all the ZFS filesystems in mountcritlocal?  I
> can't think of any negative reasons for not mounting all non-legacy
> mountable ZFS filesystems early in the boot process. This would be as
> simple as moving this chunk from mountall to mountcritlocal:
>
> # Mount ZFS filesystems first because fstab
> # may try and null mount paths on ZFS.
> if checkyesno zfs; then
> zfs mount -a
> zfs share -a
> fi
>
> and the unmount stuff from mountall to a new mountcritlocal_stop
> function.

[I don't really know what you mean by legacy (other than non-zfs, but
you didn't say that, so perhaps you mean something different).]

I think the big point here  is why do we have a notion of critical
filesystems, and if we are going to mount all zfs filesystems in
mountcritlocal, why would we then not mount all local filesystems?

AIUI, the critical notion comes from the netbooting days and sequencing
of bringing up networking to mount filesystems, which can involve
running programs that aren't on root.

I have used mountcritlocal to mount /var and /usr so that route6d could
start at the time when it is invoked by rc.d, I think, but the details
have been paged out.  I don't see that being a different issue with zfs
for / /var /usr.  Although I see it hitting more people as having
multiple filesystems is a more sensible thing to do with zfs because of
shared pool space.


If we are going to keep the critical concept, then it seems like it
should apply to all filesystems.  If we are going to abandon it, that's
a big discussion for tech-userlevel.

> For people using critical early legacy mounts, they can still be added
> via critical_filesystems_local as that looks up via /etc/fstab (right?
> I haven't tested this).

If you mean /var or /usr as ffs, I would expect so and certainly that's
necessary to support.

> Anyone see a reason for not using this much simpler approach to
> having ZFS filesystems available?  I don't think we'd need to keep
> critical_filesystems_zfs if we change mountcritlocal as I suggest, as
> that explicitly only deals with non-legacy filesystems.

I don't think it's good to treat zfs and non-zfs differently and I don't
think there are any good reasons to do so.  I also don't think its a
good idea to make ffs 2nd class.

If the big thing is to avoid having to manually mark zfs filesystems as
critical in rc.conf, fstab or some other file, and instead use a
property, that sounds like a perfectly fine solution, as the mountpoint
is already in zfs properties, and it makes sense to keep the critical
bit in the same place as the mountpoint.

However, I don't know how it works if you have a 2nd pool with a
critical filesystem and that pool doesn't come up.  (I could see
somebody having RAID1 for / /var and swap and RAIDZ for /usr and
everything else.)  From that viewpoint listing the critical filesystems
in rc.conf, leading to failure if they are not available, seems better.

It also seems like perhaps pools could be marked critical vs not so that
zfs startup can attach the critical pools first, and then the others,
but I suspect that is a lot of work for no gain, and the rc.conf
approach avoids the need.

I am really uncomfortable with a plan that comes from a place of
declaring anything but zfs as "legacy, that 

Re: CVS commit: src/etc

[Simon Burge]

[ Oops, resending to include the source-changes-d list. ]
[ Sorry for the double-up for the original recipients.  ]

Hi Alexander, folks,

Sorry for chiming in a bit late on this.

I'm running with a complete ZFS-only setup with no legacy mounts.  This
is my basic ZFS layout (leaving out a few mounts that don't add any more
value to this discussion):

NAME  MOUNTPOINT
pool0 /pool0
pool0/ROOTnone
pool0/ROOT/default/
pool0/home/home
pool0/home/simonb /home/simonb
pool0/usr /usr
pool0/usr/obj /usr/obj
pool0/usr/pkg /usr/pkg
pool0/var /var
pool0/var/crash   /var/crash
pool0/var/log /var/log
pool0/var/mail/var/mail
pool0/var/tmp /var/tmp

and I then have this grot in my mountcritlocal:

# XX
zfs mount pool0/var
zfs mount pool0/var/crash
zfs mount pool0/var/log
zfs mount pool0/var/mail
zfs mount pool0/var/tmp

I have been trying to think of better solutions to this before you added
this new critical_filesystems_zfs rc.conf variable.  One idea was to add
a user defined property (eg "netbsd:mountcrit=yes") and use that in a
similar way to how you implemented mount_critical_filesystems_zfs .  Then
another idea hit me.

Why don't we just mount all the ZFS filesystems in mountcritlocal?  I
can't think of any negative reasons for not mounting all non-legacy
mountable ZFS filesystems early in the boot process. This would be as
simple as moving this chunk from mountall to mountcritlocal:

# Mount ZFS filesystems first because fstab
# may try and null mount paths on ZFS.
if checkyesno zfs; then
zfs mount -a
zfs share -a
fi

and the unmount stuff from mountall to a new mountcritlocal_stop
function.

For people using critical early legacy mounts, they can still be added
via critical_filesystems_local as that looks up via /etc/fstab (right?
I haven't tested this).

Anyone see a reason for not using this much simpler approach to
having ZFS filesystems available?  I don't think we'd need to keep
critical_filesystems_zfs if we change mountcritlocal as I suggest, as
that explicitly only deals with non-legacy filesystems.

Cheers,
Simon.

Re: CVS commit: src/etc

[Alexander Nasonov]

Taylor R Campbell wrote:
> > Date: Sat, 5 Feb 2022 21:21:53 +
> > From: Alexander Nasonov 
> > 
> > Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
> > legacy mountpoints a try to see how much complexity they add.
> 
> I use legacy mountpoints for / and /var, but it's a little kludgey,
> and from what I recall a legacy mountpoint requires setting the
> mountpoint property explicitly on anything mounted under it.
> 
> I assumed you had made the change to obviate the need for most of this
> extra bookkeeping with fstab and explicit mountpoint properties that
> don't match the zpool dataset path.

That's right.

> So I'm guessing with your change and critical_filesystems_zfs=/var, I
> could:
> 
> - skip the fstab entry for /var,
> - have only rpool/ROOT with mountpoint=legacy, and
> - have /var and all the file systems under /var use default
>   mountpoints.

yes yes yes :)

It even supports OPTIONAL:

critical_filesystems_zfs=OPTIONAL:/var

and it's clever enough to skip "fake" mountpoints (datasets
with canmount=off).

Alex

Re: CVS commit: src/etc

[Taylor R Campbell]

> Date: Sat, 5 Feb 2022 21:21:53 +
> From: Alexander Nasonov 
> 
> Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
> legacy mountpoints a try to see how much complexity they add.

I use legacy mountpoints for / and /var, but it's a little kludgey,
and from what I recall a legacy mountpoint requires setting the
mountpoint property explicitly on anything mounted under it.

I assumed you had made the change to obviate the need for most of this
extra bookkeeping with fstab and explicit mountpoint properties that
don't match the zpool dataset path.

E.g., right now I have:

rpool/ROOT mountpoint=legacy mounted at /
rpool/ROOT/var mountpoint=legacy mounted at /var
rpool/chroot mountpoint=/var/chroot
rpool/crash mountpoint=/var/crash
rpool/home mountpoint=/home (default)
rpool/export mountpoint=/export (default)
...

and critical_filesystems_local=/var in rc.conf entries in /etc/fstab
for / and /var.  (This is all inside a chroot with the `real' /
mounted from a ramdisk, of course.)

So I'm guessing with your change and critical_filesystems_zfs=/var, I
could:

- skip the fstab entry for /var,
- have only rpool/ROOT with mountpoint=legacy, and
- have /var and all the file systems under /var use default
  mountpoints.

(I haven't looked at or tried the changes yet!)

Re: CVS commit: src/etc

[Brad Spencer]

Alexander Nasonov  writes:

> Brad Spencer wrote:
>> Alexander Nasonov  writes:
>> > Are there any downside of mixing legacy and non-legacy mountpoints?
>> > E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?
>> 
>> That should work fine as long as /var was arranged to be mounted first.
>> The other way around may and probably is trouble right now, where a
>> zpool Not-legacy needs to be mounted so that a ZFS legacy filesystem or,
>> in fact, any other filesystem type gets mounted under it.  I believe
>> that Solaris did and probably still does have this problem too.  Legacy
>> ZFS mounts should be perfectly workable even from single user when /usr
>> isn't available yet for most simple use cases.
>
> Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
> legacy mountpoints a try to see how much complexity they add.
>
> I have the following ZFS mountpoints in my setup
>
> /usr  - legacy
> /var  - legacy
> /var/log  - legacy
> /var/tmp  - normal
> /var/mail - normal
> ...
>
> Ideally, I'd like to keep all datasets under one root:
>
> tank/base/usr  - legacy
> tank/base/var  - legacy
> tank/base/var/log  - legacy
> tank/base/var/mail - normal
>
> but it has a small inconvenience: every time I add a new dataset under
> a legacy mountpoint (e.g. create a dataset for /var/spool), it can't
> inherit a mountpoint from a legacy mountpoint and I have to set it
> manually (zfs set mountpoint=/var/spool tank/base/var/spool).

Yes, that would very much be the case.  Legacy mounts in ZFS are mostly
there to make /etc/fstab (and simular ilk) work the same as one may be
used to doing, so no inheritance.  You do not have to use most of the
zpool / zfs commands to get them mounted, but at the same time you can
set their sizes and such.  Getting too complicated with them, however,
may introduce unexpected adventure.

> One way to avoid this issue is to have separate hierarchies:
>
> tank/legacy
> tank/legacy/usr
> tank/legacy/var
> tank/legacy/var/log
> tank/base
> tank/base/var
> tank/base/var/mail
>
> but I'm pretty sure it has some downsides too.
>
> Alex


-- 
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

Re: CVS commit: src/etc

[Alexander Nasonov]

Brad Spencer wrote:
> Alexander Nasonov  writes:
> > Are there any downside of mixing legacy and non-legacy mountpoints?
> > E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?
> 
> That should work fine as long as /var was arranged to be mounted first.
> The other way around may and probably is trouble right now, where a
> zpool Not-legacy needs to be mounted so that a ZFS legacy filesystem or,
> in fact, any other filesystem type gets mounted under it.  I believe
> that Solaris did and probably still does have this problem too.  Legacy
> ZFS mounts should be perfectly workable even from single user when /usr
> isn't available yet for most simple use cases.

Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
legacy mountpoints a try to see how much complexity they add.

I have the following ZFS mountpoints in my setup

/usr  - legacy
/var  - legacy
/var/log  - legacy
/var/tmp  - normal
/var/mail - normal
...

Ideally, I'd like to keep all datasets under one root:

tank/base/usr  - legacy
tank/base/var  - legacy
tank/base/var/log  - legacy
tank/base/var/mail - normal

but it has a small inconvenience: every time I add a new dataset under
a legacy mountpoint (e.g. create a dataset for /var/spool), it can't
inherit a mountpoint from a legacy mountpoint and I have to set it
manually (zfs set mountpoint=/var/spool tank/base/var/spool).

One way to avoid this issue is to have separate hierarchies:

tank/legacy
tank/legacy/usr
tank/legacy/var
tank/legacy/var/log
tank/base
tank/base/var
tank/base/var/mail

but I'm pretty sure it has some downsides too.

Alex

Re: CVS commit: src/etc

[Brad Spencer]

Alexander Nasonov  writes:

> J. Hannken-Illjes wrote:
>> What is wrong with ZFS legacy mounts?
>> 
>> $ zpool create -m legacy tank 
>> $ zfs create tank/a
>> $ mount -t zfs tank/a /mnt
>
> Hmm, I heard about ZFS legacy (quite a while ago!) but I didn't
> look into it because, well, "legacy"...
>
> Are there any downside of mixing legacy and non-legacy mountpoints?
> E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?
>
> Alex


That should work fine as long as /var was arranged to be mounted first.
The other way around may and probably is trouble right now, where a
zpool Not-legacy needs to be mounted so that a ZFS legacy filesystem or,
in fact, any other filesystem type gets mounted under it.  I believe
that Solaris did and probably still does have this problem too.  Legacy
ZFS mounts should be perfectly workable even from single user when /usr
isn't available yet for most simple use cases.



-- 
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

Re: CVS commit: src/etc

[Alexander Nasonov]

J. Hannken-Illjes wrote:
> What is wrong with ZFS legacy mounts?
> 
> $ zpool create -m legacy tank 
> $ zfs create tank/a
> $ mount -t zfs tank/a /mnt

Hmm, I heard about ZFS legacy (quite a while ago!) but I didn't
look into it because, well, "legacy"...

Are there any downside of mixing legacy and non-legacy mountpoints?
E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?

Alex

Re: CVS commit: src/etc

[Martin Husemann]

On Fri, Feb 04, 2022 at 10:19:03PM +, Alexander Nasonov wrote:
> These two "styles of mounting" are
> 
> /sbin/mount /filesystem - looks up fs parameters in /etc/fstab
> /sbin/zfs mount dataset - looks up fs parameters in zpools

There are several things that could be done here. I would guess some
of these also need a "special string" solution (see below) for booting
from ZFS.

I was (maybe eroneously) assuming common usage would be to mount all 
filesystems from a zpool, so expecting something like a
critical_zpools_local variable for a list of zpools that need mounting
early.

Then for special cases I would expect mount_zfs to understand some special
string (and the same type of string being passed in from the bootloader
for root on ZFS), so I could do:

mount zfs:${guid-or-name-of-zpool}:${fs-identifier} /home

and have the equivalent of that in /etc/fstab. And then of course the
legacy mounts, as Jürgen pointed out.

But I am no ZFS expert, and just wanted to note that there is some
"design not yet fully complete" feeling with the current state of
integration of ZFS into NetBSD - which also might just mean it is not
yet properly documented. I really appreciate all the work going into this,
and would like to see sysinst support and boot with root on ZFS, and good
docs for all of it, for netbsd-10 (on amd64 at least).

Martin

Re: CVS commit: src/etc

[J. Hannken-Illjes]

> On 4. Feb 2022, at 23:19, Alexander Nasonov  wrote:
> 
> Martin Husemann wrote:
>> On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
>>> variable, it will mix two very different styles of mounting and
>>> compilate the code.
> 
> s/compilate/complicate/
> 
>> "different styles of mounting" sounds like a non-starter to me, maybe
>> that should be fixed first?
> 
> These two "styles of mounting" are
> 
> /sbin/mount /filesystem - looks up fs parameters in /etc/fstab
> /sbin/zfs mount dataset - looks up fs parameters in zpools
> 
> I don't think these two approaches can be unified.

What is wrong with ZFS legacy mounts?

$ zpool create -m legacy tank 
$ zfs create tank/a
$ mount -t zfs tank/a /mnt

> We surely
> can modify mount_critical_systems to try entries from /etc/fstab
> first, and if /sbin/mount fails, then try to find a zfs dataset
> for the failed entry and /sbin/zfs mount it. But if things go
> wrong, a complicated mounting process will make troubleshooting
> harder. For that reason, I'd like to keep mountcrit_zfs separate
> from mountcrit_local.

--
J. Hannken-Illjes - hann...@mailbox.org


signature.asc
Description: Message signed with OpenPGP

Re: CVS commit: src/etc

[Alexander Nasonov]

Martin Husemann wrote:
> On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
> > variable, it will mix two very different styles of mounting and
> > compilate the code.

s/compilate/complicate/

> "different styles of mounting" sounds like a non-starter to me, maybe
> that should be fixed first?

These two "styles of mounting" are

/sbin/mount /filesystem - looks up fs parameters in /etc/fstab
/sbin/zfs mount dataset - looks up fs parameters in zpools

I don't think these two approaches can be unified. We surely
can modify mount_critical_systems to try entries from /etc/fstab
first, and if /sbin/mount fails, then try to find a zfs dataset
for the failed entry and /sbin/zfs mount it. But if things go
wrong, a complicated mounting process will make troubleshooting
harder. For that reason, I'd like to keep mountcrit_zfs separate
from mountcrit_local.

Alex

Re: CVS commit: src/etc

[Martin Husemann]

On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
> variable, it will mix two very different styles of mounting and
> compilate the code.

"different styles of mounting" sounds like a non-starter to me, maybe
that should be fixed first?

Martin

Re: CVS commit: src/etc

[Alexander Nasonov]

Hi Robert,

Robert Elz wrote:
> A couple of comments about your mount_critical_filesystems_zfs()
> function in rc.subr

Thank you for reviewing my code!

> It starts:
> 
>   eval _fslist=\$critical_filesystems_zfs
> 
> I'm not sure what you're attempting to accomplish there.

I copied this line from mount_critical_filesystems:

eval _fslist=\$critical_filesystems_${1}

and changed ${1} to zfs without realising that I don't need eval
anymore.

>...
>_dataset=`
> 
> (followed by a lengthy command substitution).   Please don't use ``
> command substitutions, they are fragile, and essentially obsolete.

Noted.

I don't like the approach I took but I'm not very comfortable in
a bare shell when tools in /usr aren't (yet) available and this
giant $() was all I could think of.

> The only excuse for ever using them in anything modern is if the
> script might need to be run by a truly ancient shell.   Just use $( )
> instead, the semantics are much cleaner.
> 
> And perhaps more important, near the bottom of the big loop:
> 
>   if [ "$_mount_es" != 0 ]; then
>   _mountcrit_es="$_mount_es"
>   fi
> 
> which causes the exit status of the function (_mountcrit_es) to be the
> status of the last mount that failed for some reason, rather than the
> first (which tends to be more common).

These lines is a copy/paste from mount_critical_filesystems and
your comment apply to that function too.

>...
> One additional minor point, it might be better to use -ne there instead
> of != since the values are intended to be integers, rather than strings.
> But that doesn't really matter (unless $_mount_es might be "" in which
> case using != is better - that would be 0 for -ne, but not 0 for !=).

Yes, it's intended to be integers.

--
Alex

Re: CVS commit: src/etc

[Alexander Nasonov]

Alexander Nasonov wrote:
> Module Name:  src
> Committed By: alnsn
> Date: Thu Feb  3 20:52:44 UTC 2022
> 
> Modified Files:
>   src/etc: rc.subr
> 
> Log Message:
> Add mount_critical_filesystems_zfs
> 
> The new function is similar to mount_critical_filesystems
> but it walks through ZFS datasets and mounts matching entries.

I plan to intoduce a new rc.conf variable critical_filesystems_zfs
which is essentially the same as critical_filesystems_local but
for ZFS.

Although the new variable can be avoided if my code is merged into
existing mount_critical_filesystems(), and all critical filesystems
(ZFS or not) are mounted in one pass through critical_filesystems_local
variable, it will mix two very different styles of mounting and
compilate the code. One extra variable shouldn't be a problem for
most users but it will help to keep rc.subr neater.

--
Alex

Re: CVS commit: src/etc

[Robert Elz]

A couple of comments about your mount_critical_filesystems_zfs()
function in rc.subr

It starts:

eval _fslist=\$critical_filesystems_zfs

I'm not sure what you're attempting to accomplish there.  The eval
command sees
fslist=$critical_filesystems_zfs
(the \ having quoted the '$' preventing variable expansion, and
was then removed).

eval uses that as input, and runs it.   But if that was what you
wanted, why bother with eval at all, just write it as eval sees it.

eval is most useful when some of the arg string is to come from a
variable that is expanded before eval sees it, which isn't the case here.

Later:

 _dataset=`

(followed by a lengthy command substitution).   Please don't use ``
command substitutions, they are fragile, and essentially obsolete.
The only excuse for ever using them in anything modern is if the
script might need to be run by a truly ancient shell.   Just use $( )
instead, the semantics are much cleaner.

And perhaps more important, near the bottom of the big loop:

if [ "$_mount_es" != 0 ]; then
_mountcrit_es="$_mount_es"
fi

which causes the exit status of the function (_mountcrit_es) to be the
status of the last mount that failed for some reason, rather than the
first (which tends to be more common).   Perhaps "zfs mount" only ever
does exit(1) for any error, in which case it doesn't matter (1 from any
execution is the same thing) but if it returns different exit codes
depending upon the error, you usually want the first one, rather than
the last - particularly with filesystem mounting, it isn't unusual for
later mounts to fail if an earlier one did, if the earlier one was
intended to provide the mount points, for example - knowing that the
later mounts failed because the directory they intended to mount onto
wasn't present is fairly useless, what you want to know is why the
earlier one failed.

One additional minor point, it might be better to use -ne there instead
of != since the values are intended to be integers, rather than strings.
But that doesn't really matter (unless $_mount_es might be "" in which
case using != is better - that would be 0 for -ne, but not 0 for !=).

kre

Re: CVS commit: src/etc

[Christos Zoulas]

In article <20220105014628.9f952f...@cvs.netbsd.org>,
Robert Elz  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  kre
>Date:  Wed Jan  5 01:46:28 UTC 2022
>
>Modified Files:
>   src/etc: Makefile
>
>Log Message:
>Install the missing sh syntax element in the MKDEBUGKERNEL = no test, so
>that "continue" is a command as intended, and not an invalid last arg to
>the '[' command (the last arg is required to be ']').
>
>Sometime the proverbial someone should go through this and remove all the
>obsolete test -o and -a operators, and probably do something with test's
>usage of ! as well.   Not today, or not by me anyway.

Thanks! I was wondering where this [: message was coming from...

christos

Re: CVS commit: src/etc/rc.d

[Martin Husemann]

On Tue, Nov 30, 2021 at 10:11:36AM +, Stephen Borrill wrote:
> In our products, we have a standard rc.conf and then a series of build
> scripts that configure and enable/disable services as required. We can
> switch between npf and ipfilter with a one-line change in a settings file,
> for example. We heavily rely on rc.conf.d functionality for this. We may put
> flags in there too.

You could achive that too by including "local" files from your generic 
/etc/rc.conf (like: ". /etc/conf/firewall", maybe even guarded by tests
for existance).

> I don't think putting name=YES into /etc/rc.conf.d/name is wrong or working
> by luck in general even if it is working by implication.

If we want to support that, we should document it and have tests for
it. Currently I would not guess this could work after reading the manual,
and would not think about such usage when extending/modifying anything in
/etc/rc*.

> I think the "load_rc_config_var npf npf" line I've proposed in npf_boot is a
> neat solution (and similar for pf_boot). It basically says get the value of
> npf from wherever you may find it. It also avoids potential contamination of
> the environment compared to my original fix.

Yes, and I am not objecting that detail.

> The split of /etc/rc.d/npf into two stages is analogous to swap1 and swap2.
> In that case, those scripts explicitly load_rc_config swap and do not take
> name into account.

We should ammend the documentation Robert cited to say something like
"in general $name, but in exceptional cases a well known service name
is used instead (like: swap, npf, ...)".

Martin

Re: CVS commit: src/etc/rc.d

[Stephen Borrill]

On 30/11/2021 09:43, Martin Husemann wrote:

On Tue, Nov 30, 2021 at 09:10:35AM +, Stephen Borrill wrote:

In rc.conf, npf=YES is sufficient, but you are advocating the setting needs
to be duplicated if put into rc.conf.d.


I think the confusion starts with the idea of enabling NPF by just
putting the NPF=yes into scripts in /etc/rc.conf.d.

It might have worked by pure luck in older releases, but it was wrong there
too.

I would argue that to enable it you should have NPF=yes in /etc/rc.conf,
and to override special stuff in the $name script  (which I can't think
of reasonable uses for this case) you would put that overrides into
/etc/rc.conf.d/$name.


In our products, we have a standard rc.conf and then a series of build 
scripts that configure and enable/disable services as required. We can 
switch between npf and ipfilter with a one-line change in a settings 
file, for example. We heavily rely on rc.conf.d functionality for this. 
We may put flags in there too.


I don't think putting name=YES into /etc/rc.conf.d/name is wrong or 
working by luck in general even if it is working by implication.


I think the "load_rc_config_var npf npf" line I've proposed in npf_boot 
is a neat solution (and similar for pf_boot). It basically says get the 
value of npf from wherever you may find it. It also avoids potential 
contamination of the environment compared to my original fix.


The split of /etc/rc.d/npf into two stages is analogous to swap1 and 
swap2. In that case, those scripts explicitly load_rc_config swap and do 
not take name into account.



--
Stephen

Re: CVS commit: src/etc/rc.d

[Martin Husemann]

On Tue, Nov 30, 2021 at 09:10:35AM +, Stephen Borrill wrote:
> In rc.conf, npf=YES is sufficient, but you are advocating the setting needs
> to be duplicated if put into rc.conf.d.

I think the confusion starts with the idea of enabling NPF by just
putting the NPF=yes into scripts in /etc/rc.conf.d.

It might have worked by pure luck in older releases, but it was wrong there
too.

I would argue that to enable it you should have NPF=yes in /etc/rc.conf,
and to override special stuff in the $name script  (which I can't think
of reasonable uses for this case) you would put that overrides into
/etc/rc.conf.d/$name.


Martin

Re: CVS commit: src/etc/rc.d

[Stephen Borrill]

On 26/11/2021 17:52, Robert Elz wrote:

 Date:Fri, 26 Nov 2021 13:11:36 +
 From:"Stephen Borrill" 
 Message-ID:  <20211126131136.63fabf...@cvs.netbsd.org>

   | Load rc configuration based on rcvar, not name, so that correct settings
   | in /etc/rc.conf.d are loaded.

This looks wrong to me (and a pullup request so soon after making a
change, before it has had any time for testing in HEAD is a *really*
bad idea).

   | Usually this does not matter as rcvar and name are set to the same value.
   | For pf_boot and npf_boot, rcvar is set to pf and npf respectively.
   |
   | Prior to the change, if:
   | rc.conf contains npf=YES
   | rc.conf.d/npf does not exist

Nor should it, that's not the file that is supposed to be used.

In rc.conf(5):


 rc.d(8) scripts that use load_rc_config from rc.subr(8) also support
 sourcing an optional end-user provided per-script override file
 /etc/rc.conf.d/service, (where service is the contents of the name
 variable in the rc.d(8) script).

That is, what should happen to make this work...

   | If:
   | rc.conf contains npf=NO (or is not set)
   | rc.conf.d/npf contains npf=YES

is that rc.conf.d/npf_boot should contain npf=YES

The rc.conf.d files have the same names as the rc.d/script files in
general, for good reason, as while they often only contain this
rcvar setting, they can contain overrides to anything in the script.
Further, if there is more than one rcvar in a script (which I think
has happened once or twice) the settings for both of them would go
in the same file, not one file for each of them.

   | This means that in the latter case, at boot time the npfctl start command
   | is never run and the firewall is not operational.

Because of user error.

Please revert this change, and request the pullup be undone as well.
I don't think it is as simple as this in the case of npf and pf. What 
has happened here is that the functionality of /etc/rc.d/npf has 
effectively been split into two parts (one to run early, the other 
late). It does not make sense to run one without the other. It's not 
like nfs which is a stack of mountd, rpcbind, nfsd, etc. which may well 
want different flags for each.


In rc.conf, npf=YES is sufficient, but you are advocating the setting 
needs to be duplicated if put into rc.conf.d. When upgrading from 8 to 
9, this is a breaking change.


I propose an alternative fix which is to change /etc/rc.d/npf_boot to read:

load_rc_config $name
load_rc_config_var npf npf

--
Stephen

Re: CVS commit: src/etc/rc.d

[Robert Elz]

Date:Fri, 26 Nov 2021 13:11:36 +
From:"Stephen Borrill" 
Message-ID:  <20211126131136.63fabf...@cvs.netbsd.org>

  | Load rc configuration based on rcvar, not name, so that correct settings
  | in /etc/rc.conf.d are loaded.

This looks wrong to me (and a pullup request so soon after making a
change, before it has had any time for testing in HEAD is a *really*
bad idea).

  | Usually this does not matter as rcvar and name are set to the same value.
  | For pf_boot and npf_boot, rcvar is set to pf and npf respectively.
  |
  | Prior to the change, if:
  | rc.conf contains nfp=YES
[ignoring the typo there]
  | rc.conf.d/npf does not exist

Nor should it, that's not the file that is supposed to be used.

In rc.conf(5):


rc.d(8) scripts that use load_rc_config from rc.subr(8) also support
sourcing an optional end-user provided per-script override file
/etc/rc.conf.d/service, (where service is the contents of the name
variable in the rc.d(8) script).

That is, what should happen to make this work...

  | If:
  | rc.conf contains npf=NO (or is not set)
  | rc.conf.d/npf contains npf=YES

is that rc.conf.d/npf_boot should contain npf=YES

The rc.conf.d files have the same names as the rc.d/script files in
general, for good reason, as while they often only contain this
rcvar setting, they can contain overrides to anything in the script.
Further, if there is more than one rcvar in a script (which I think
has happened once or twice) the settings for both of them would go
in the same file, not one file for each of them.

  | This means that in the latter case, at boot time the npfctl start command
  | is never run and the firewall is not operational.

Because of user error.

Please revert this change, and request the pullup be undone as well.

kre

Re: CVS commit: src/etc/rc.d

[Robert Elz]

Date:Mon, 2 Aug 2021 20:02:28 +0900
From:Rin Okuyama 
Message-ID:  <21dae7de-f153-2e53-4e66-cc61c8241...@gmail.com>

quoting Michael van Elst: 
  | > If you insist on a separate barrier, one name would be USERDEVICEPATHS
  | > or short UDEV.

UDEV (or UDEVS) sounds good to me.   WEDGENAMES (or WNAMES) would work as well.

  | I think it is simplest to install zfs unconditionally

It would be, if we knew that the only thing that will ever need it
is zfs - but we don't, with wedge names becoming more and more used
more users are likely to find things that need names for them, rather
than dkN's.   Modifying everything to support NAME= would be one way
(that could be done for zfs I assume) but might be lots of work.
Making sure things depend upon devpubd (or perhaps some alternative
scheme someone comes up with someday) sounds like a better long term
plan to me.

kre

Re: CVS commit: src/etc/rc.d

[Rin Okuyama]

On 2021/08/02 19:15, Michael van Elst wrote:

On Mon, Aug 02, 2021 at 11:27:22AM +0200, Michael van Elst wrote:

On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:

Hi,

this commit causes:

rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'

for systems with MKZFS=no.

Install /etc/rc.d/zfs for everyone? This should be harmless; the script
properly checks existence of /sbin/zfs, i.e., MKZFS=yes.

Alternatively, autogen /etc/rc.d/devpubd?



I'd prefer installing /etc/rc.d/zfs for everyone.

Michael van Elst



The alternative is to change the direction of the dependency. I don't
think you need a separate BARRIER script for this unless you have some
plan to add more than devpubd as a requirement.

For this add an additional "REQUIRE: devpubd" to zfs, ccd, cgd, lvm,
and raidframe and drop "BEFORE: zfs ccd cgd lvm raidframe" from devpubd.

If you insist on a separate barrier, one name would be USERDEVICEPATHS
or short UDEV.


I think it is simplest to install zfs unconditionally, but
I don't have strong opinions.

Thanks,
rin

Re: CVS commit: src/etc/rc.d

[Michael van Elst]

On Mon, Aug 02, 2021 at 11:27:22AM +0200, Michael van Elst wrote:
> On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
> > Hi,
> > 
> > this commit causes:
> > 
> > rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
> > 
> > for systems with MKZFS=no.
> > 
> > Install /etc/rc.d/zfs for everyone? This should be harmless; the script
> > properly checks existence of /sbin/zfs, i.e., MKZFS=yes.
> > 
> > Alternatively, autogen /etc/rc.d/devpubd?
> 
> 
> I'd prefer installing /etc/rc.d/zfs for everyone.
> 
> Michael van Elst


The alternative is to change the direction of the dependency. I don't
think you need a separate BARRIER script for this unless you have some
plan to add more than devpubd as a requirement.

For this add an additional "REQUIRE: devpubd" to zfs, ccd, cgd, lvm, 
and raidframe and drop "BEFORE: zfs ccd cgd lvm raidframe" from devpubd.

If you insist on a separate barrier, one name would be USERDEVICEPATHS
or short UDEV.


Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: CVS commit: src/etc/rc.d

[Michael van Elst]

On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
> Hi,
> 
> this commit causes:
> 
>   rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
> 
> for systems with MKZFS=no.
> 
> Install /etc/rc.d/zfs for everyone? This should be harmless; the script
> properly checks existence of /sbin/zfs, i.e., MKZFS=yes.
> 
> Alternatively, autogen /etc/rc.d/devpubd?


I'd prefer installing /etc/rc.d/zfs for everyone.

Michael van Elst



> 
> Thanks,
> rin
> 
> On 2021/07/31 23:47, Michael van Elst wrote:
> > Module Name:src
> > Committed By:   mlelstv
> > Date:   Sat Jul 31 14:47:04 UTC 2021
> > 
> > Modified Files:
> > src/etc/rc.d: devpubd
> > 
> > Log Message:
> > Run devpubd before volume managers and pseudo disks.
> > 
> > 
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.1 -r1.2 src/etc/rc.d/devpubd
> > 
> > Please note that diffs are not public domain; they are subject to the
> > copyright notices on the relevant files.
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: CVS commit: src/etc/rc.d

[Martin Husemann]

On Mon, Aug 02, 2021 at 12:44:01PM +0700, Robert Elz wrote:
> Date:Mon, 2 Aug 2021 11:54:27 +0900
> From:Rin Okuyama 
> Message-ID:  
> 
>   | Install /etc/rc.d/zfs for everyone?
> 
> Add a new dummy rc.d script (like LOGIN or DISKS)
> have devpubd come before that, and everything
> which should come later require it.
> 
> That's cleaner.   We should probably have a
> few more of them for the startup stages, even
> if they're not really needed yet, and far
> fewer real scripts depending on each other
> except where there is a genuine relationship.

Seconded, like what I did with /etc/rc.d/CRITLOCALMOUNTED recently (which also
shows the hardest part of the game: find a proper name, and beware of
case-insensitive-but-case-preserving source filesystems that we still support
cross builds from).

Martin

Re: CVS commit: src/etc/rc.d

[Robert Elz]

Date:Mon, 2 Aug 2021 11:54:27 +0900
From:Rin Okuyama 
Message-ID:  

  | Install /etc/rc.d/zfs for everyone?

Add a new dummy rc.d script (like LOGIN or DISKS)
have devpubd come before that, and everything
which should come later require it.

That's cleaner.   We should probably have a
few more of them for the startup stages, even
if they're not really needed yet, and far
fewer real scripts depending on each other
except where there is a genuine relationship.

kre

Re: CVS commit: src/etc/rc.d

[Rin Okuyama]

Hi,

this commit causes:

rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'

for systems with MKZFS=no.

Install /etc/rc.d/zfs for everyone? This should be harmless; the script
properly checks existence of /sbin/zfs, i.e., MKZFS=yes.

Alternatively, autogen /etc/rc.d/devpubd?

Thanks,
rin

On 2021/07/31 23:47, Michael van Elst wrote:

Module Name:src
Committed By:   mlelstv
Date:   Sat Jul 31 14:47:04 UTC 2021

Modified Files:
src/etc/rc.d: devpubd

Log Message:
Run devpubd before volume managers and pseudo disks.


To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/etc/rc.d/devpubd

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/etc/mtree

[Roy Marples]

On 30/09/2020 08:55, matthew green wrote:

Module Name:src
Committed By:   mrg
Date:   Wed Sep 30 07:55:31 UTC 2020

Modified Files:
src/etc/mtree: NetBSD.dist.tests

Log Message:
add missing new if_vether subdir.


Thanks!

Re: CVS commit: src/etc/rc.d

[rudolf]

Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Mon Apr  9 15:02:39 UTC 2018

Modified Files:
src/etc/rc.d: sshd

Log Message:
Simplify so we don't have to hard-code the key filenames in two places.



There are some leftovers in the script after the simplification, the 
"version" and "name" input arguments are unused now. Please see the 
attached diff.


Kind regards,

r.
diff --git a/etc/rc.d/sshd b/etc/rc.d/sshd
index 038f817ebe43..dfc4d0b91077 100755
--- a/etc/rc.d/sshd
+++ b/etc/rc.d/sshd
@@ -20,7 +20,7 @@ sshd_keygen()
 (
 	keygen="/usr/bin/ssh-keygen"
 	umask 022
-	while read type bits filename version name;  do
+	while read type bits filename;  do
 		f="/etc/ssh/$filename"
 		if [ -f "$f" ]; then
 			continue
@@ -33,10 +33,10 @@ sshd_keygen()
 		"${keygen}" -t "${type}" ${bitarg} -f "${f}" -N '' -q && \
 		printf "ssh-keygen: " && "${keygen}" -f "${f}" -l
 	done << _EOF
-dsa	1024	ssh_host_dsa_key	2	DSA
-ecdsa	521	ssh_host_ecdsa_key	1	ECDSA
-ed25519	-1	ssh_host_ed25519_key	1	ED25519
-rsa	0	ssh_host_rsa_key	2	RSA
+dsa	1024	ssh_host_dsa_key
+ecdsa	521	ssh_host_ecdsa_key
+ed25519	-1	ssh_host_ed25519_key
+rsa	0	ssh_host_rsa_key
 _EOF
 )
 }

Re: CVS commit: src/etc

[Robert Elz]

Sorry about commit msg.  should have said...

install rc.d/smtoff and provide defaults/rc.conf
setting for it

Attempting to work from my phone while waiting
for car to be serviced

Re: CVS commit: src/etc

[Pierre Pronchery]

On 14/01/2019 12:27, m...@netbsd.org wrote:
> [...]
> This does give the ability to configure wifi with a GUI w/o root or
> something akin to polkit, via some pkgsrc packages (There's wpa_gui, for
> example, it's a QT5 thing. I imagine writing other things is not much
> harder)

Yes, that's also what x11/deforaos-panel uses to configure wireless.

> I just figured this change might be controversial so we need to be
> honest about it happening.

The change Roy made is something I also perform systematically on any
system I install and expect to connect to a wireless networks. It is
harmless when wpa_supplicant(8) is not running.

I agree that a dedicated group to allow network configuration would be
nice. However users in the "wheel" group are usually expected to be
allowed to su(1) anyway, and I think the balance is already very good
with this group to perform the corresponding privileged operations
without prompting for a password nor exposing too much.

Cheers,
-- 
khorben

Re: CVS commit: src/etc

[maya]

On Mon, Jan 14, 2019 at 01:08:27AM +, David Holland wrote:
> On Mon, Jan 14, 2019 at 09:42:54AM +1100, matthew green wrote:
>  > it would be OK if this was _read-only_ access to network
>  > configuration, but one should never be allowed to change the
>  > it unless root.
> 
> In the long run, it's quite helpful for laptops to be able to adjust
> the network configuration from a GUI on the console without having to
> run GUI bits as root. We aren't in a position to do this correctly
> (nor does importing the likes of polkit as a hack to allow reasoning
> about being "on the console" constitute correctly) but let's not lose
> track of it as a goal.
> 
> Is there a way we could, for example, leverage the current hacks for
> chowning console devices to grant access to wpa_supplicant?
> 
> -- 
> David A. Holland
> dholl...@netbsd.org

This does give the ability to configure wifi with a GUI w/o root or
something akin to polkit, via some pkgsrc packages (There's wpa_gui, for
example, it's a QT5 thing. I imagine writing other things is not much
harder)

I just figured this change might be controversial so we need to be
honest about it happening.

Re: CVS commit: src/etc

[Robert Elz]

Date:Mon, 14 Jan 2019 11:59:51 +1100
From:matthew green 
Message-ID:  <10889.1547427...@splode.eterna.com.au>

  | i don't agree with this.
  |
  | if we were going to make things easy for naive users

I didn't say "easy" for naive users, I said "most useful".   That might
mean "suitably secure" rather than "simply works" and is a different
discussion.

One possibility here, might be to make configuration classes,
like "laptop" "workstation" "server" (whatever we want) and
have different default configurations for different system types,
so while I certainly wouldn't let non-root be configuring my servers
in any way at all, I don't really want to be root in order to
configure my laptop (at least to decide which wireless SSID
it should connect to, or when wireless should be disabled
when I am on a plane).

We could also have different security levels, "locked down",
"adequate", "better than nothing", and "absent" and have
different default configurations for those as well.

And then it would be easy for sysint to ask the user which
type of system this is (it would often be able to intuit a
reasonable default from the config) and what level of
security they want, and set those at the the same time it
is setting rc_configured=YES.

Aside from working out exactly what the values for the
various configs should be for whatever different modes
we create, all of this is trivial.

kre

Re: CVS commit: src/etc

[Greg Troxel]

matthew green  writes:

> (i wouldn't pick 'wheel' as this group -- i would invent a
> new group either called 'net' or 'wpa', with no underscore
> since they're designed to be assigned, unlike the groups
> for specific programs security models.)

Are you saying that you are ok with the following:

   add a new group "net"

   by default, nobody is in it

   it's ok for things that modify networking config to allow this to be
   done by users in group net, in addition to root

   (so therefore, absent configuration by root, there are no additional
   privileges compared to now)

?

If so, that seems like a reasonable compromise compared to letting wheel
modify networking, and calling it "net" lets this be a logical privilege
in general, even if wpa config is the only thing right now.

Re: CVS commit: src/etc

[Jason Thorpe]

> On Jan 13, 2019, at 5:08 PM, David Holland 
>  wrote:
> 
> Is there a way we could, for example, leverage the current hacks for
> chowning console devices to grant access to wpa_supplicant?

Some of this could be achieved with ttyaction(5), certainly.

-- thorpej

Re: CVS commit: src/etc

[David Holland]

On Mon, Jan 14, 2019 at 09:42:54AM +1100, matthew green wrote:
 > it would be OK if this was _read-only_ access to network
 > configuration, but one should never be allowed to change the
 > it unless root.

In the long run, it's quite helpful for laptops to be able to adjust
the network configuration from a GUI on the console without having to
run GUI bits as root. We aren't in a position to do this correctly
(nor does importing the likes of polkit as a hack to allow reasoning
about being "on the console" constitute correctly) but let's not lose
track of it as a goal.

Is there a way we could, for example, leverage the current hacks for
chowning console devices to grant access to wpa_supplicant?

-- 
David A. Holland
dholl...@netbsd.org

re: CVS commit: src/etc

[matthew green]

>   | i don't want to allow [...]
> 
> People, once again, a big meaningless discussion on what the
> default configuration should be.We should work out what will
> be most useful to most naive users, and make that be the default,
> regardless of what any of us want.

i don't agree with this.

if we were going to make things easy for naive users we'd give
up almost any pretense of security at all.  i'm not talking about
general configuration, but security configuration.

AFAICT, we care a lot about security.  allowing network configuration
to be done by some new class of users is not what i consider a
secure default.  at the very least, this point must be considered
and chosen, rather than some contested commit enabling it.

infact, i was trying to say it would be great if this worked better
out of the box -- but i don't see why non-root should be allowed to
change network configuration by default.  wheel is a stepping stone
in the security layering, please don't skip over it.


.mrg.

Re: CVS commit: src/etc

[Robert Elz]

In my previous message, I forgot to also note that if
modifying (if required) wpa_supplicant to create the
socket with the ownership & permissions set in the
rc.conf file is too hard (would create issues with importing
new versions easily) then the same can be accomplished
by putting the socket in a sub-dir (it is already I believe)
and applying the permissions to the gating directory,
then the socket just needs to be made 666 mode and
we're all happy.

And incidentally, why is (even before the recent
changes, I haven't updated to those in systems I
use yet) the socket created 770 mode ?   What does
'x' mean to a socket?   Does that have some magic
meaning I'm unaware of, or is this just sloppy?

kre

Re: CVS commit: src/etc

[Robert Elz]

Date:Mon, 14 Jan 2019 09:42:54 +1100
From:matthew green 
Message-ID:  <11338.1547419...@splode.eterna.com.au>

  | > I suppose the real question is do we want to allow group access to 
  | > [...]

  | i don't want to allow [...]

People, once again, a big meaningless discussion on what the
default configuration should be.We should work out what will
be most useful to most naive users, and make that be the default,
regardless of what any of us want.

For the rest of us, what we need is the ability to configure to suit
our own desires.

So perhaps an rc.conf setting like

WPA_MODES=077:user:group

or something, to select the umask to use when creating the
socket (or the inverse to set the perms) and the user and
group that should own it.   Then just decide what is best
to set that to for the default config, and everyone here can
adjust as needed in our own systems.

For my personal preference (not to be considered when deciding
what is the default setup) I'd prefer wheel group to be able to config
the (wireless) network (which is all that is in question here, right?
nothing is allowing non-root to edit rc.conf or /etc/ifconfig.xx0)

On my phone I don't need to be root to decide which wireless net
to connect to, I can't imagine why I would need to be on my laptop.
But to each their own (ie: there is no need for anyone to explain why
they prefer what they prefer for their systems ... just stop demanding
that the default config be what you want on your system.)

I prefer wheel as the group, over creating a new one, not because a
new one is much harder to deal with, but if we keep creating new
specific groups (that people actually join, unlike the _ groups) then
eventually we'll reach the point where some users need to be in more
than NGROUPS groups, and things stop working (and as I recall,
NGROUPS being exceeded does not result in any obvious feedback).

kre

re: CVS commit: src/etc

[matthew green]

Roy Marples writes:
> On 13/01/2019 10:20, matthew green wrote:
> > shouldn't one need to be root to modify network configuration?
> > i shouldn't be able to tell wpa_supplicant to do something as
> > non-root, in a default install.
> 
> In a default install the only member of wheel is root and wpa_supplicant 
> is not started.
> 
> I suppose the real question is do we want to allow group access to 
> wpa_supplicant and if so which group if not wheel?
> 
> If we don't want to allow group access I may as well revert my changes 
> and setup is then as before - the user is expected to configure 
> everything themselves and wpa_cli won't work by default. This would be a 
> shame as I've had a lot of positive feedback on this change already.

i don't want to allow configuration changes by non root.
that should be fairly obvious and not something anyone would
question.

group 'wheel' means access to root, not that it gives you
additional privs immediately.  if it did there would be no
point in having group 'wheel' -- may as well just make all
the wheel users uid 0, since that is the security provided.

it would be OK if this was _read-only_ access to network
configuration, but one should never be allowed to change the
it unless root.  ie, i'm not objecting to having a better
default wpa_supplicant configuration, but don't remove
security layers in the process.

(i wouldn't pick 'wheel' as this group -- i would invent a
new group either called 'net' or 'wpa', with no underscore
since they're designed to be assigned, unlike the groups
for specific programs security models.)


.mrg.

Re: CVS commit: src/etc

[Greg Troxel]

Jason Thorpe  writes:

>> On Jan 13, 2019, at 5:21 AM, Greg Troxel  wrote:
>> 
>> Even if you have to be root, these changes are still hugely useful.
>> "sudo wpa_cli" is not that hard, even if it seems like it should not be
>> necessary.
>
> ...but made slightly more annoying seeing as how sudo is not part of the base 
> OS.

s/sudo wpa_cli/su root -c wpa_cli/

But yes, it is harder.  I had to read the su man page (back when I was
young, we didn't have sudo and had to use su uphill both ways after
toggling in the boot loader).

Re: CVS commit: src/etc

[Jason Thorpe]

> On Jan 13, 2019, at 5:21 AM, Greg Troxel  wrote:
> 
> Even if you have to be root, these changes are still hugely useful.
> "sudo wpa_cli" is not that hard, even if it seems like it should not be
> necessary.

...but made slightly more annoying seeing as how sudo is not part of the base 
OS.

-- thorpej

Re: CVS commit: src/etc

[Greg Troxel]

Roy Marples  writes:

> On 13/01/2019 10:20, matthew green wrote:
>> shouldn't one need to be root to modify network configuration?
>> i shouldn't be able to tell wpa_supplicant to do something as
>> non-root, in a default install.
>
> In a default install the only member of wheel is root and
> wpa_supplicant is not started.
>
> I suppose the real question is do we want to allow group access to
> wpa_supplicant and if so which group if not wheel?

That is indeed the real question.  As I see it wheel has historically
been a group for users that are system administrators, given how "su"
only allows users in wheel to su.  So it seems reasonable to allow
various configuration changes by users in wheel.

It seems the only point in putting somebody in wheel now is if you tell
them the root pw, to let them su.  Are there other reasons?

Another approach is to create a wpa_supplicant group, and allow wpa
changes by those in that group.  I can't see any reasonable objection to
this, other than group bloat.

> If we don't want to allow group access I may as well revert my changes
> and setup is then as before - the user is expected to configure
> everything themselves and wpa_cli won't work by default. This would be
> a shame as I've had a lot of positive feedback on this change already.

Even if you have to be root, these changes are still hugely useful.
"sudo wpa_cli" is not that hard, even if it seems like it should not be
necessary.

re: CVS commit: src/etc

[matthew green]

shouldn't one need to be root to modify network configuration?
i shouldn't be able to tell wpa_supplicant to do something as
non-root, in a default install.


.mrg.

Re: CVS commit: src/etc

[Roy Marples]

Not really, it just sets the group explicitly rather than implicitly. Without 
it the socket group is derived from the directory it's created in, which is 
group wheel to start with.

Now it could be argued that creating the socket in the first place allows 
members of the wheel group to configure wpa_supplicant and thus connect to a 
network. I don't see this as a problem myself and I believe that wpa_cli should 
work by default if wpa is enabled.

Roy


On 12 January 2019 19:05:23 GMT, m...@netbsd.org wrote:
>This lets any user in wheel group choose to connect to the network.
>Isn't that more privileges than we normally give?
>
>On Sat, Jan 12, 2019 at 04:51:55PM +, Roy Marples wrote:
>> +ctrl_interface_group=wheel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: CVS commit: src/etc

[maya]

This lets any user in wheel group choose to connect to the network.
Isn't that more privileges than we normally give?

On Sat, Jan 12, 2019 at 04:51:55PM +, Roy Marples wrote:
> +ctrl_interface_group=wheel

Re: CVS commit: src/etc/etc.evbarm

[Herbert J. Skuhra]

On Tue, 06 Nov 2018 14:36:06 +0100, "Herbert J. Skuhra" wrote:
> 
> On Mon, 05 Nov 2018 22:37:31 +0100, Nick Hudson wrote:
> > 
> > On 05/11/2018 20:45, Herbert J. Skuhra wrote:
> > > On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:
> > >> "Herbert J. Skuhra"  writes:
> > >> 
> > >>> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
> >  
> >  Module Name:   src
> >  Committed By:  skrll
> >  Date:  Sun Nov  4 21:41:12 UTC 2018
> >  
> >  Modified Files:
> > src/etc/etc.evbarm: Makefile.inc
> >  
> >  Log Message:
> >  Only add GENERIC to earmv6 and earmv7 builds
> > >>> 
> > >>> This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U 
> > >>> release".
> > 
> > fixed. (I hope)
> > 
> > > My Raspberry boots, grows /, reboots and then panics. This happens for
> > > several days now. :-(
> > 
> > What's the panic message and backtrace?
> 
> [  13.5062763] Fatal kernel mode prefetch abort at 0x
> [  13.5062763] trapframe: 0xb9b45ef0, spsr=a0090013
> [  13.5062763] r0 =742871c8, r1 =f2a00e00, r2 =b9b45fb0, r3 =0010
> [  13.5062763] r4 =80799648, r5 =, r6 =b9b45fb0, r7 =742871c8
> [  13.5062763] r8 =0010, r9 =f2a00e00, r10=ba87a920, r11=b9b45fac
> [  13.5062763] r12=b9b45f40, ssp=b9b45f40, slr=80023890, pc =
> 
> Stopped in pid 191.1 (syslogd) at   0:  address 0x0 is invalid
> andeq   r0, r0, r0
> db{2}> bt
> 0xb9b45fac: netbsd:undefinedinstruction+0xc
> 
> If I disable syslogd I get a similar error with makemandb.

earmv6hf works fine!

--
Herbert

Re: CVS commit: src/etc/etc.evbarm

[Herbert J. Skuhra]

On Mon, 05 Nov 2018 22:37:31 +0100, Nick Hudson wrote:
> 
> On 05/11/2018 20:45, Herbert J. Skuhra wrote:
> > On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:
> >> "Herbert J. Skuhra"  writes:
> >> 
> >>> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
>  
>  Module Name: src
>  Committed By:skrll
>  Date:Sun Nov  4 21:41:12 UTC 2018
>  
>  Modified Files:
>   src/etc/etc.evbarm: Makefile.inc
>  
>  Log Message:
>  Only add GENERIC to earmv6 and earmv7 builds
> >>> 
> >>> This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U 
> >>> release".
> 
> fixed. (I hope)
> 
> > My Raspberry boots, grows /, reboots and then panics. This happens for
> > several days now. :-(
> 
> What's the panic message and backtrace?

[  13.5062763] Fatal kernel mode prefetch abort at 0x
[  13.5062763] trapframe: 0xb9b45ef0, spsr=a0090013
[  13.5062763] r0 =742871c8, r1 =f2a00e00, r2 =b9b45fb0, r3 =0010
[  13.5062763] r4 =80799648, r5 =, r6 =b9b45fb0, r7 =742871c8
[  13.5062763] r8 =0010, r9 =f2a00e00, r10=ba87a920, r11=b9b45fac
[  13.5062763] r12=b9b45f40, ssp=b9b45f40, slr=80023890, pc =

Stopped in pid 191.1 (syslogd) at   0:  address 0x0 is invalid
andeq   r0, r0, r0
db{2}> bt
0xb9b45fac: netbsd:undefinedinstruction+0xc

If I disable syslogd I get a similar error with makemandb.

--
Herbert

Re: CVS commit: src/etc/etc.evbarm

[Herbert J. Skuhra]

On Tue, Nov 06, 2018 at 12:58:54AM +, m...@netbsd.org wrote:
> On Mon, Nov 05, 2018 at 09:45:38PM +0100, Herbert J. Skuhra wrote:
> > With etc/etc.evbarm/Makefile.inc r1.97 the command completes. I only
> > have to fix the build of groff (PR #53314) by removing/commenting out
> > the following lines in obj/tools/groff/build/src/include/config.h:
> > 
> > #define NEED_DECLARATION_GETTIMEOFDAY 1
> > #define NEED_DECLARATION_PUTENV 1
> > #define NEED_DECLARATION_SRAND 1
> > #define NEED_DECLARATION_STRNCASECMP 1
> 
> on -8 its fixed it with
> https://releng.netbsd.org/cgi-bin/req-8.cgi?show=1070

Adding HOST_CXXFLAGS to tools/Makefile.gnuhost fixes the issue:

--- tools/Makefile.gnuhost  22 Oct 2018 13:19:42 -  1.51
+++ tools/Makefile.gnuhost  6 Nov 2018 07:14:01 -
@@ -22,6 +22,7 @@
 HOST_COMPILER_CLANG!= if ${HOST_CC} --version | grep -q -s clang; then echo 
yes; else echo no; fi
 .if ${HOST_COMPILER_CLANG} == "yes"
 HOST_CFLAGS+=-O2 -no-cpp-precomp
+HOST_CXXFLAGS+=-std=gnu++03
 .endif
 
 MAKE_PROGRAM?= ${MAKE}



Thanks.

-- 
Herbert 

Re: CVS commit: src/etc/etc.evbarm

[Herbert J. Skuhra]

On Mon, Nov 05, 2018 at 09:37:31PM +, Nick Hudson wrote:
> On 05/11/2018 20:45, Herbert J. Skuhra wrote:
> > On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:
> > > "Herbert J. Skuhra"  writes:
> > > 
> > > > On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
> > > > > 
> > > > > Module Name:  src
> > > > > Committed By: skrll
> > > > > Date: Sun Nov  4 21:41:12 UTC 2018
> > > > > 
> > > > > Modified Files:
> > > > >   src/etc/etc.evbarm: Makefile.inc
> > > > > 
> > > > > Log Message:
> > > > > Only add GENERIC to earmv6 and earmv7 builds
> > > > 
> > > > This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U 
> > > > release".
> 
> fixed. (I hope)

Yes, the build completes again.

> > My Raspberry boots, grows /, reboots and then panics. This happens for
> > several days now. :-(
> 
> What's the panic message and backtrace?

I have to take a screenshot or transcribe it. I'll post this information
later today.

Thanks.

-- 
Herbert

Re: CVS commit: src/etc/etc.evbarm

[Greg Troxel]

Greg Troxel  writes:

> "Herbert J. Skuhra"  writes:
>
>> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
>>> 
>>> Module Name:src
>>> Committed By:   skrll
>>> Date:   Sun Nov  4 21:41:12 UTC 2018
>>> 
>>> Modified Files:
>>> src/etc/etc.evbarm: Makefile.inc
>>> 
>>> Log Message:
>>> Only add GENERIC to earmv6 and earmv7 builds
>>
>> This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U release".
>
> That seems like an unusual invocation.   Do you really mean it that way,
> instead of -a evbarm?   Passing earmv7hf to -a is an alias which sets
> both a amd m, and then the line is also setting m.Why do you include
> '-m evbarm' - what cpu type are you trying to build for?

Sorry, I was confused and wrote from memory and got it wrong.  You are
entirely right about your invocation.

I just actually read build.sh and adjusted the wording in the wiki.

Re: CVS commit: src/etc/etc.evbarm

[maya]

On Mon, Nov 05, 2018 at 09:45:38PM +0100, Herbert J. Skuhra wrote:
> With etc/etc.evbarm/Makefile.inc r1.97 the command completes. I only
> have to fix the build of groff (PR #53314) by removing/commenting out
> the following lines in obj/tools/groff/build/src/include/config.h:
> 
> #define NEED_DECLARATION_GETTIMEOFDAY 1
> #define NEED_DECLARATION_PUTENV 1
> #define NEED_DECLARATION_SRAND 1
> #define NEED_DECLARATION_STRNCASECMP 1

on -8 its fixed it with
https://releng.netbsd.org/cgi-bin/req-8.cgi?show=1070

Re: CVS commit: src/etc/etc.evbarm

[Nick Hudson]

On 05/11/2018 20:45, Herbert J. Skuhra wrote:

On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:

"Herbert J. Skuhra"  writes:


On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:


Module Name:src
Committed By:   skrll
Date:   Sun Nov  4 21:41:12 UTC 2018

Modified Files:
src/etc/etc.evbarm: Makefile.inc

Log Message:
Only add GENERIC to earmv6 and earmv7 builds


This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U release".


fixed. (I hope)


My Raspberry boots, grows /, reboots and then panics. This happens for
several days now. :-(


What's the panic message and backtrace?

Thanks,
Nick

Re: CVS commit: src/etc/etc.evbarm

[Herbert J. Skuhra]

On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:
> "Herbert J. Skuhra"  writes:
> 
> > On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
> >> 
> >> Module Name:   src
> >> Committed By:  skrll
> >> Date:  Sun Nov  4 21:41:12 UTC 2018
> >> 
> >> Modified Files:
> >>src/etc/etc.evbarm: Makefile.inc
> >> 
> >> Log Message:
> >> Only add GENERIC to earmv6 and earmv7 builds
> >
> > This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U release".
> 
> That seems like an unusual invocation.   Do you really mean it that way,
> instead of -a evbarm?   Passing earmv7hf to -a is an alias which sets
> both a amd m, and then the line is also setting m.Why do you include
> '-m evbarm' - what cpu type are you trying to build for?

I am trying to build an image for my Raspberry Pi 2B on FreeBSD
12.0-BETA3 and I am just following the instructions from
:


CPU types

Raspberry Pi 1 uses "earmv6hf".
Raspberry Pi 2 uses "earmv7hf".
Raspberry Pi 3 uses "earmv7hf".

Building yourself

Getting sources and building a release with build.sh is not special for
evbarm. Pick a CPU type alias and pass it to build.sh with -m. Examples
(the first two are equivalent):

./build.sh -m earmv6hf -u release
./build.sh -m evbarm -a earmv6hf -u release
./build.sh -m evbarm -a earmv7hf -u release
 

With etc/etc.evbarm/Makefile.inc r1.97 the command completes. I only
have to fix the build of groff (PR #53314) by removing/commenting out
the following lines in obj/tools/groff/build/src/include/config.h:

#define NEED_DECLARATION_GETTIMEOFDAY 1
#define NEED_DECLARATION_PUTENV 1
#define NEED_DECLARATION_SRAND 1
#define NEED_DECLARATION_STRNCASECMP 1

My Raspberry boots, grows /, reboots and then panics. This happens for
several days now. :-(

-- 
Herbert

Re: CVS commit: src/etc/etc.evbarm

[Greg Troxel]

"Herbert J. Skuhra"  writes:

> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
>> 
>> Module Name: src
>> Committed By:skrll
>> Date:Sun Nov  4 21:41:12 UTC 2018
>> 
>> Modified Files:
>>  src/etc/etc.evbarm: Makefile.inc
>> 
>> Log Message:
>> Only add GENERIC to earmv6 and earmv7 builds
>
> This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U release".

That seems like an unusual invocation.   Do you really mean it that way,
instead of -a evbarm?   Passing earmv7hf to -a is an alias which sets
both a amd m, and then the line is also setting m.Why do you include
'-m evbarm' - what cpu type are you trying to build for?

Re: CVS commit: src/etc/etc.evbarm

[Herbert J. Skuhra]

On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
> 
> Module Name:  src
> Committed By: skrll
> Date: Sun Nov  4 21:41:12 UTC 2018
> 
> Modified Files:
>   src/etc/etc.evbarm: Makefile.inc
> 
> Log Message:
> Only add GENERIC to earmv6 and earmv7 builds

This change obviously breaks "./build.sh -m evbarm -a earmv7hf -U release".

mv: rename /tmp/mkimage.zyfOkH/mnt/boot/sun50i-* to 
/tmp/mkimage.zyfOkH/mnt/boot/allwinner/sun50i-*: No such file or directory  
   

*** Failed target:  smp_armv7

--
Herbert

Re: CVS commit: src/etc

[Robert Elz]

Date:Sun, 30 Sep 2018 21:40:18 +0200
From:Joerg Sonnenberger 
Message-ID:  <20180930194018.ga11...@britannica.bec.de>

  | Just for the future, a better way would be to use :Uno or similar.

Yes, I thought there was a method like that, but make "programmming"
is not my thing, and I was not sure I would (ever) get the syntax correct,
so ...

kre

Re: CVS commit: src/etc

[Joerg Sonnenberger]

On Sat, Sep 29, 2018 at 01:12:22AM +, Robert Elz wrote:
> Module Name:  src
> Committed By: kre
> Date: Sat Sep 29 01:12:22 UTC 2018
> 
> Modified Files:
>   src/etc: Makefile
> 
> Log Message:
> Only test USE_XZ_SETS if it is defined.   This is probably not the
> correct fix, so someone else please do it correctly - either this is
> the wrong word, or it should be given a default value elsewhere.

Just for the future, a better way would be to use :Uno or similar.

Joerg

Re: CVS commit: src/etc

[Martin Husemann]

On Sat, Sep 29, 2018 at 01:12:22AM +, Robert Elz wrote:
> Module Name:  src
> Committed By: kre
> Date: Sat Sep 29 01:12:22 UTC 2018
> 
> Modified Files:
>   src/etc: Makefile
> 
> Log Message:
> Only test USE_XZ_SETS if it is defined.   This is probably not the
> correct fix, so someone else please do it correctly - either this is
> the wrong word, or it should be given a default value elsewhere.

Ooops, sorry about that.
For now it is the correct fix - the default will be set, but that part
of the changes has not been commited yet.

Martin

Re: CVS commit: src/etc

[Martin Husemann]

On Thu, Jul 26, 2018 at 08:23:19AM +0200, Maxime Villard wrote:
> Le 24/07/2018 à 21:45, Thomas Klausner a écrit :
> > On Tue, Jul 24, 2018 at 07:10:38PM +0200, Maxime Villard wrote:
> > > > Is this something that we should let postinstall fix?
> > > > Or what is the upgrade strategy for the users not reading 
> > > > source-changes?
> > > 
> > > Now that I stumbled across it while browsing mail-index.netbsd.org:
> > > doesn't postinstall use MAKEDEV.tmpl already?
> > 
> > AFAICT, the script itself (/dev/MAKEDEV) is updated, but created nodes
> > are not.
> 
> Then that is a missing feature of postinstall, am I right?

No, that is on purpose. Admin may do arbitrary changes to /dev/* ownership
and rights.

In this case I would suggest to add a special test for too broad rights,
warn, and propose a command for manual fixing.

Martin

Re: CVS commit: src/etc

[Maxime Villard]

Le 24/07/2018 à 21:45, Thomas Klausner a écrit :

On Tue, Jul 24, 2018 at 07:10:38PM +0200, Maxime Villard wrote:

Is this something that we should let postinstall fix?
Or what is the upgrade strategy for the users not reading source-changes?


Now that I stumbled across it while browsing mail-index.netbsd.org:
doesn't postinstall use MAKEDEV.tmpl already?


AFAICT, the script itself (/dev/MAKEDEV) is updated, but created nodes
are not.


Then that is a missing feature of postinstall, am I right?

Re: CVS commit: src/etc

[Maxime Villard]

Is this something that we should let postinstall fix?
Or what is the upgrade strategy for the users not reading source-changes?


If you send your answer to me on a mailing list I'm not subscribed to,
without even CC'ing me, I'm just never going to see your mail.

Now that I stumbled across it while browsing mail-index.netbsd.org:
doesn't postinstall use MAKEDEV.tmpl already?


Le 21/07/2018 à 09:46, Maxime Villard a écrit :

Module Name:src
Committed By:   maxv
Date:   Sat Jul 21 07:46:56 UTC 2018

Modified Files:
src/etc: MAKEDEV.tmpl

Log Message:
Create /dev/ksyms as "440 $g_kmem". This prevents unprivileged users from
reading the kernel symbols. Discussed in January 2018 on tech-kern@,
reported by maya@, tested by tih@.


To generate a diff of this commit:
cvs rdiff -u -r1.190 -r1.191 src/etc/MAKEDEV.tmpl

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/etc/rc.d

[Taylor R Campbell]

> Module Name:src
> Committed By:   christos
> Date:   Sat Apr  7 00:41:16 UTC 2018
> 
> Modified Files:
> src/etc/rc.d: sshd
> 
> Log Message:
> support xmss keys

I advise against generating XMSS host keys by default.

The XMSS signature scheme is stateful, so managing XMSS keys is
qualitatively different for an administrator from all the other
signature schemes supported here: roll back the state (e.g., from disk
backup or VM snapshot) and you shoot yourself in the foot.

There's no benefit right now to post-quantum signature because
practical quantum computers are still a long way out.  Future quantum
computers pose no _retroactive_ danger for online authentication: if
quantum computers ever do become practical, you can replace the host
keys and all _subsequent_ sessions will be fine.

(The story is different for confidentiality; post-quantum public-key
key agreement and encryption are more important to deploy now because
of the possibility of retroactive decryption.)

Re: CVS commit: src/etc

[Valery Ushakov]

PR bin/52905 (typo in the pr number in the log message).

On Sat, Jan 06, 2018 at 23:44:06 +, Michael van Elst wrote:

> Module Name:  src
> Committed By: mlelstv
> Date: Sat Jan  6 23:44:06 UTC 2018
> 
> Modified Files:
>   src/etc: security
> 
> Log Message:
> Use sysctl to retrieve iostat names instead of parsing possibly
> truncated iostat output.
> 
> Check dkctl listwedges output with grep.
> 
> Fixes PR 59205.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.121 -r1.122 src/etc/security
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.

-uwe

Re: CVS commit: src/etc/rc.d

[David Holland]

On Wed, Dec 06, 2017 at 08:25:08AM +0700, Robert Elz wrote:
 > It isn't the precedence of the operators that is at issue, but
 > deciding what is an operator -

oh right, I'm pretty sure I knew about that at one point and blocked
it out for the sake of my sanity :-)

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/etc/rc.d

[Robert Elz]

Date:Tue, 5 Dec 2017 16:00:25 +
From:David Holland 
Message-ID:  <20171205160025.ga22...@netbsd.org>

  | Test -o isn't well specified? Or is the issue the precedence of ! vs. -o?

-o is a "to be deprecated one day" option, but that is not really the
problem (our test will continue to support it anyway.)

It isn't the precedence of the operators that is at issue, but deciding what is
an operator - all of the args to test are merely strings, and the strings
that are to be operands can have values like "!" or "-o" (or "-f"  "=" or "(")
as easily as those intended to be operators (or syntax.)

That makes it very difficult to work out which args are operators and
which are operands (there is no notion of quoting in test arg strings.)

To handle this, there are a set of rules that specify exactly how to parse
a test expression that has 0 to 4 args (though even there there are undefined
cases) and any expression with more than 4 args is simply undefined (the
trailing ']' when test is called as '[' does not count as an arg for this
purpose.)

The expression in rc.d/sshd would not have caused any problems, but it
sets a bad example - and as it is always trivial to convert a long test
expression (with an obvious intent) into a series of shorter defined
cases connected by sh operators, I do that whenever I see an undefined
use - whether it will work as written or not.

The change from
test ! -f filename
to
! test -f filename

(or really the [ form that is/was there) is not strictly necessary right now
- but it would be if some later revision to test were to add a new binary
operator "-f" to accompany the current unary "-f" operator - which might be
unlikely but is not impossible, so, as the change is trivial, it might as
well be done too.

In general, if you are using any of ! ( ) -o -a  as test args, and they
are not intended to be simple strings to be operated upon, it is best to
rewrite the command, using sh operators and syntax to combine sub-expressions.
Just remember when doing it that in test, -a is (was) higher precedence than -o
but in sh && and || are equal precedence, and associate L to R, so sometimes
extra { } need to be added.

kre

Re: CVS commit: src/etc/rc.d

[David Holland]

On Mon, Dec 04, 2017 at 02:50:33PM +, Robert Elz wrote:
 > Modified Files:
 >  src/etc/rc.d: sshd
 > 
 > Log Message:
 > Do away with (not well specified, even if it happens to work) absurd
 > 15 arg test ([ ]) expression, and replace it with several well defined
 > 2 arg tests, combined with (also well defined) sh syntax.

Test -o isn't well specified? Or is the issue the precedence of ! vs. -o?

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/etc/namedb

[Takahiro Kambe]

In message <20171025074135.8b844f...@cvs.netbsd.org>
on Wed, 25 Oct 2017 07:41:35 +,
"Takahiro Kambe"  wrote:
> Module Name:  src
> Committed By: taca
> Date: Wed Oct 25 07:41:35 UTC 2017
> 
> Modified Files:
>   src/etc/namedb: root.cache
> 
> Log Message:
> /tmp/t
Should be:

Update root.cache to 2017102400 (October 24, 2017).

B.ROOT-SERVERS.NET's IPv4 and IPv6 address has changed.

XXX Pull-up to netbsd-6, netbsd-7 and netbsd-8

-- 
Takahiro Kambe 

Re: CVS commit: src/etc/mtree

[Jared McNeill]

On Sat, 21 Oct 2017, Robert Elz wrote:


Log Message:
Create directory for new bwfm firmware to be installed into.


Thank you!

Re: CVS commit: src/etc/etc.next68k

[Christos Zoulas]

On Jul 8, 12:47pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/etc/etc.next68k

| > | The PR says:
| > | > This information should be fixed to reflect reality, or 
etc/etc.next68k/MAKEDEV.conf should build tty[ab] as done on e.g. sparc.
| > | 
| > | What makes you choose the latter?
| > 
| > That every arch except alpha uses ttya and ttyb for zstty?
| 
| In which file? zs(4) man page?

Yes.

christos

Re: CVS commit: src/etc/etc.next68k

[Izumi Tsutsui]

> | The PR says:
> | > This information should be fixed to reflect reality, or 
> etc/etc.next68k/MAKEDEV.conf should build tty[ab] as done on e.g. sparc.
> | 
> | What makes you choose the latter?
> 
> That every arch except alpha uses ttya and ttyb for zstty?

In which file? zs(4) man page?

---
Izumi Tsutsui

Re: CVS commit: src/etc/etc.next68k

[Izumi Tsutsui]

The PR says:
> This information should be fixed to reflect reality, or 
> etc/etc.next68k/MAKEDEV.conf should build tty[ab] as done on e.g. sparc.

What makes you choose the latter?

---
Izumi Tsutsui

Re: CVS commit: src/etc/etc.next68k

[Christos Zoulas]

On Jul 8, 11:41am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/etc/etc.next68k

| The PR says:
| > This information should be fixed to reflect reality, or 
etc/etc.next68k/MAKEDEV.conf should build tty[ab] as done on e.g. sparc.
| 
| What makes you choose the latter?

That every arch except alpha uses ttya and ttyb for zstty?

christos

Re: CVS commit: src/etc/etc.next68k

[Christos Zoulas]

On Jul 8, 11:31am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/etc/etc.next68k

| IMO man page should be updated to mention "ttyZ[01]",
| as MI src/etc/MAKEDEV.tmpl does.
| 
| tty[ab] were derived from sun3 and sparc, which followed SunOS ones.
| 
| Other ports used tty0[01] etc. but IIRC it caused conflicts with tty0?
| of com(4) on ports which has both zs(4) and com(4) when MI MAKEDEV.tmpl
| was introduced.  Then there was discussion to use ttyC? for com(4) and
| ttyZ? for zs(4) if there was no histrical restrictions.

Feel free to change it the way you feel is best.

christos

Re: CVS commit: src/etc/etc.next68k

[Izumi Tsutsui]

> Module Name:  src
> Committed By: christos
> Date: Fri Jul  7 23:48:34 UTC 2017
> 
> Modified Files:
>   src/etc/etc.next68k: MAKEDEV.conf
> 
> Log Message:
> PR/52377: Miod Vallat: Provide links to ttya and ttyb as mentioned in zs(4)

IMO man page should be updated to mention "ttyZ[01]",
as MI src/etc/MAKEDEV.tmpl does.

tty[ab] were derived from sun3 and sparc, which followed SunOS ones.

Other ports used tty0[01] etc. but IIRC it caused conflicts with tty0?
of com(4) on ports which has both zs(4) and com(4) when MI MAKEDEV.tmpl
was introduced.  Then there was discussion to use ttyC? for com(4) and
ttyZ? for zs(4) if there was no histrical restrictions.

---
Izumi Tsutsui

Re: CVS commit: src/etc

[Christos Zoulas]

In article <20170116093926.99ca3f...@cvs.netbsd.org>,
Hauke Fath  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  hauke
>Date:  Mon Jan 16 09:39:26 UTC 2017
>
>Modified Files:
>   src/etc: protocols
>
>Log Message:
>Add carp as an alias for vrrp - after all, we do not ship vrrp, but we
>do ship carp(4).
>
>Restore the pfsync entry that was added with 1.20, then wiped out by
>the 1.21 import. Please merge any wholesale imports properly.
>
>Remove http://www.sethwklein.net/projects/iana-etc/ which 404s.

This is not how this used to work; you need to add those entries to the
local portion. If that does not work, we need to figure out how to
merge them automatically.

christos

Re: CVS commit: src/etc/etc.atari

[Joerg Sonnenberger]

On Fri, Jan 29, 2016 at 06:03:16PM +, Izumi Tsutsui wrote:
> Module Name:  src
> Committed By: tsutsui
> Date: Fri Jan 29 18:03:16 UTC 2016
> 
> Modified Files:
>   src/etc/etc.atari: MAKEDEV.conf
> 
> Log Message:
> Drop almost unnecessary devices for floppy to shrink sysinst.fs.
> 
> Briefly tested on TT030.

Is the change of opty to ipty intentional?

Joerg

re: CVS commit: src/etc/mtree

[matthew green]

Takeshi Nakayama writes:
 Module Name:  src
 Committed By: nakayama
 Date: Wed Aug 12 21:55:05 UTC 2015
 
 Modified Files:
   src/etc/mtree: NetBSD.dist.base
 
 Log Message:
 Remove obsolete directory ./usr/include/gcc-4.5

thanks.  i meant to do this.

and thanks for fixing the sparc builds.


.mrg.

Re: CVS commit: src/etc/mtree

[Joerg Sonnenberger]

On Sun, Jun 28, 2015 at 09:28:46AM +, Martin Husemann wrote:
 Module Name:  src
 Committed By: martin
 Date: Sun Jun 28 09:28:46 UTC 2015
 
 Modified Files:
   src/etc/mtree: Makefile
 
 Log Message:
 Guard a few $MK... != no tests by an additional defined(MK...) clause
 and make the emit_dist_file target depend on EXTRA_DIST_FILES.
 Part of fixing PR toolchain/50004.

Please use :U for those.

Joerg

Re: CVS commit: src/etc

[Erik Fair]

On Jan 8, 2014, at 10:25 , Greg Troxel g...@ir.bbn.com wrote:

 Why do you think the configured servers should be given query
 permission?  Is that a sense of courtesy to the pool operators that they
 should be able to run ntpdc -c monlist and ntpq -p at machines that
 are syncing from them?

Yes, that's polite. It is suggested by the NTP peering guidelines (and I know 
server and peer are different).

Erik f...@netbsd.org

Re: CVS commit: src/etc

[Greg Troxel]

Alan Barrett a...@netbsd.org writes:

 If you have restrict default nopeer noquery (the uncommented line in
 my commit), then time service will still work, but the configured
 servers will be denied query permission.

 If you use restrict default ignore, then time service does not work.

I have found the ntp restrict situation very confusing.  I think that
all we need to do is something like:

restrict default noquery nomodify notrap
restrict -6 default noquery nomodify notrap
restrict 127.0.0.1
restrict -6 ::1

and leave it at that.  The real issue is amplification via monlist.  I
don't understand the apparent leap from that to almost completely
firewalling ntp.

Why do you think the configured servers should be given query
permission?  Is that a sense of courtesy to the pool operators that they
should be able to run ntpdc -c monlist and ntpq -p at machines that
are syncing from them?


pgpfSjBwi1PQ5.pgp
Description: PGP signature

Re: CVS commit: src/etc

[Erik Fair]

Unless I misunderstand NTP configuration semantics, your additional restrict 
statements for the NTP pool names will do the wrong thing, in that each 
reference to a given netbsd.pool.ntp.org name returns multiple IP addresses, in 
apparently random order, i.e. an attempt to guarantee no two queries return the 
same data.

Ergo, those restrict statements will most probably not end up with the same IP 
address as their preceding server statements, as was presumably your intent.

Erik f...@netbsd.org

Re: CVS commit: src/etc

[Alan Barrett]

On Mon, 06 Jan 2014, Erik Fair wrote:
Unless I misunderstand NTP configuration semantics, your 
additional restrict statements for the NTP pool names 
will do the wrong thing, in that each reference to a given 
netbsd.pool.ntp.org name returns multiple IP addresses, in 
apparently random order, i.e. an attempt to guarantee no two 
queries return the same data.


Ergo, those restrict statements will most probably not end up 
with the same IP address as their preceding server statements, 
as was presumably your intent.


Yes, you are correct.  What should we do?

If you have restrict default nopeer noquery (the uncommented 
line in my commit), then time service will still work, but the 
configured servers will be denied query permission.


If you use restrict default ignore, then time service does not 
work.


--apb (Alan Barrett)

Re: CVS commit: src/etc/mtree

[Joerg Sonnenberger]

On Wed, Aug 21, 2013 at 08:52:45PM +, Matthias Scheler wrote:
 Module Name:  src
 Committed By: tron
 Date: Wed Aug 21 20:52:45 UTC 2013
 
 Modified Files:
   src/etc/mtree: NetBSD.dist.base
 
 Log Message:
 Remove more obsolete directories:
 - /usr/include/gcc-4.1

This is not true, i.e. vax still uses GCC 4.1.

Joerg

Re: CVS commit: src/etc/rc.d

[Nicolas Joly]

On Fri, Dec 14, 2012 at 06:42:26PM +, Alan Barrett wrote:
 Module Name:  src
 Committed By: apb
 Date: Fri Dec 14 18:42:25 UTC 2012
 
 Modified Files:
   src/etc/rc.d: random_seed
 
 Log Message:
 Avoid using programs from /usr/bin.  This should fix PR 47326.
 
 - no need for dirname, because df -G can take a file name directly.
 - replace use of awk with a shell while read loop.
 - replace use of stat -s with ls -ldn.
 - no need for tail now that the use of stat has changed.
 
 While here, also add some shell quotes and improve the grammar in a comment.

With this change, i do still see a bootstrap problem when
${random_file} doesn't exists ...

njoly@lynche [~]# ls -l /var/db/entropy-file
ls: /var/db/entropy-file: No such file or directory
root@lynche [~]# /etc/rc.d/random_seed stop
df: /var/db/entropy-file: No such file or directory

Actually, if the file does not exists it will fail to create one.

random_save()
{
oum=$(umask)
umask 077

rm -Pf ${random_file}

if ! fs_safe ${random_file}; then
return 1
fi

if rndctl -S ${random_file}; then
echo Saved entropy to disk.
fi
}

First, rm(1) is called before fs_safe() check which will always
fail. Even with the rm call commented or better moved just before
rndctl, the fs_safe call will fail in df(1) if file does not already
exists. Chicken or Egg ...

-- 
Nicolas Joly

Biology IT Center
Institut Pasteur, Paris.

Re: CVS commit: src/etc/rc.d

[dieter roelants]

On Tue, 4 Dec 2012 17:39:42 +0100
Marc Balmer m...@msys.ch wrote:

 
 Am 04.12.2012 um 17:38 schrieb Patrick Welche pr...@netbsd.org:
 
  Module Name:src
  Committed By:   prlw1
  Date:   Tue Dec  4 16:38:40 UTC 2012
  
  Modified Files:
  src/etc/rc.d: ntpd ppp
  
  Log Message:
  Make sure that ntpd creates a pid file for the rc machinery to work.
  http://mail-index.netbsd.org/current-users/2012/11/19/msg021518.html
 
 How is that related to ppp?  Was that an accidental commit?

I don't know, but I think an entry for ppp should be added to
etc/defaults/rc.conf.

kind regards
dieter

 
  
  Please note that diffs are not public domain; they are subject to the
  copyright notices on the relevant files.
  
  
  Index: src/etc/rc.d/ppp
  diff -u src/etc/rc.d/ppp:1.8 src/etc/rc.d/ppp:1.9
  --- src/etc/rc.d/ppp:1.8Mon Oct 11 15:00:51 2004
  +++ src/etc/rc.d/pppTue Dec  4 16:38:40 2012
  @@ -1,6 +1,6 @@
  #!/bin/sh
  #
  -# $NetBSD: ppp,v 1.8 2004/10/11 15:00:51 christos Exp $
  +# $NetBSD: ppp,v 1.9 2012/12/04 16:38:40 prlw1 Exp $
  #
  
  # PROVIDE: ppp
  @@ -14,6 +14,7 @@
  $_rc_subr_loaded . /etc/rc.subr
  
  name=ppp
  +rcvar=$name
  start_cmd=ppp_start
  stop_cmd=ppp_stop
  sig_stop=-INT
  @@ -40,6 +41,8 @@ ppp_start()
  fi
  done
  echo .
  +   else
  +   warn \${ppp_peers} is not set - pppd was not started.
  fi
  }