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

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

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

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

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

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

Re: CVS commit: src/etc

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

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

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

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

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

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

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

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 >

Re: CVS commit: src/etc

[ 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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

> 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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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,

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

> 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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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 '$'

Re: CVS commit: src/etc

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. > > > >

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

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

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

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

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

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

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

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

Re: CVS commit: src/etc/mtree

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

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

Re: CVS commit: src/etc

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

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

Re: CVS commit: src/etc

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,

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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:

Re: CVS commit: src/etc

> 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

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

re: CVS commit: src/etc

> | 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.

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

> 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.

Re: CVS commit: src/etc

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 >

re: CVS commit: src/etc

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

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

Re: CVS commit: src/etc

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

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: > > >> > > >>>

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

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

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

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

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

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: > > > > > > > >

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

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

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

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

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

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

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

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

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

"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

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

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

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

> 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

Re: CVS commit: src/etc

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

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

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

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

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

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

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

Re: CVS commit: src/etc/namedb

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

Re: CVS commit: src/etc/mtree

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

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. | > | | &g

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? ---

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? --- Izumi Tsutsui

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

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 cho

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

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. | | O

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

> 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

Re: CVS commit: src/etc

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 -

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

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.

re: CVS commit: src/etc/mtree

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

Re: CVS commit: src/etc/mtree

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

Re: CVS commit: src/etc

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?

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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,

Re: CVS commit: src/etc/mtree

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

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

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

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

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

  1   2   3   >