Module Name: src
Committed By:jmmv
Date:Fri Feb 5 16:29:02 UTC 2010
Modified Files:
src/etc: daily security
src/etc/defaults: daily.conf security.conf
Log Message:
Deprecate the pkgdb_dir settings from daily.conf and security.conf
On Fri, Jun 04, 2010 at 02:42:55PM -0400, Christos Zoulas wrote:
> Modified Files:
> src/etc: rc rc.subr
>
> Log Message:
> print human readable exit code.
+ elif [ $1 -eq 127 ]
+ then
+ echo "stopped with signal $(expr $1 / 256)"
that can't be right...
--
D
On Sun, Jun 06, 2010 at 08:37:57AM -0400, Christos Zoulas wrote:
> Modified Files:
> src/etc: rc.subr
>
> Log Message:
> fix conditional, from dholland.
That makes a lot more sense :-)
(but now I'm wondering if sh should provide some kind of
WIFEXITED/WEXITSTATUS logic so we don't have
On Sun, Sep 19, 2010 at 08:52:23PM +, Jonathan A. Kollasch wrote:
> Log Message:
> Make pci(4) device nodes root:wheel 0640 by default.
> Mortals do not need to be able to generate PCI Configuration Space
> read transactions, which are not entirely without side effect, as
> reported in PR#
On Thu, 28 Jul 2011, Marc Balmer wrote:
Modified Files:
src/etc: ntp.conf
Log Message:
Remove duplicate (but commented out) entries.
I think the duplicates were deliberate. The idea is that names
like foo.pool.ntp.org are associated with many IP addresses,
and if you use the name tw
Alan Barrett wrote:
> On Thu, 28 Jul 2011, Marc Balmer wrote:
> >Modified Files:
> > src/etc: ntp.conf
> >
> >Log Message:
> >Remove duplicate (but commented out) entries.
>
> I think the duplicates were deliberate. The idea is that names
> like foo.pool.ntp.org are associated with many IP
"Simon Burge" writes:
> Module Name: src
> Committed By: simonb
> Date: Thu Jul 28 22:28:07 UTC 2011
>
> Modified Files:
> src/etc: ntp.conf
>
> Log Message:
> Restore "duplicate" entries, but use 0. and 1. names to ensure that
> same hosts aren't used by both entries.
> # Northe
Am 29.07.11 10:03, schrieb Aleksej Saushev:
> "Simon Burge" writes:
>
>> Module Name: src
>> Committed By:simonb
>> Date:Thu Jul 28 22:28:07 UTC 2011
>>
>> Modified Files:
>> src/etc: ntp.conf
>>
>> Log Message:
>> Restore "duplicate" entries, but use 0. and 1. names
> Module Name: src
> Committed By: jym
> Date: Mon Aug 22 18:54:06 UTC 2011
>
> Modified Files:
> src/etc: Makefile
> src/etc/defaults: Makefile rc.conf
> Added Files:
> src/etc/etc.amd64: rc.conf
> src/etc/etc.i386: rc.conf
>
> Log Message:
> Modify etc/defaults
On Mon, Aug 22, 2011 at 06:54:07PM +, Jean-Yves Migeon wrote:
> Module Name: src
> Committed By: jym
> Date: Mon Aug 22 18:54:06 UTC 2011
>
> Modified Files:
> src/etc: Makefile
> src/etc/defaults: Makefile rc.conf
> Added Files:
> src/etc/etc.amd64: rc.conf
>
On 06.09.2011 12:54, Thomas Klausner wrote:
> On Mon, Aug 22, 2011 at 06:54:07PM +, Jean-Yves Migeon wrote:
>> Module Name: src
>> Committed By:jym
>> Date:Mon Aug 22 18:54:06 UTC 2011
>>
>> [snip]
>>
>> Log Message:
>> Modify etc/defaults/Makefile so that architectures
On Tue, Sep 06, 2011 at 01:48:41PM +0200, Jean-Yves Migeon wrote:
> Hmmm, /etc/defaults/rc.conf should be transparent to postinstall(8), as
> it gets installed via during build.sh.
>
> If the source ('-s' of postinstall(8)) is not specified at command line,
> according to code it takes "/usr/src"
On 06.09.2011 21:29, Thomas Klausner wrote:
>> If the source ('-s' of postinstall(8)) is not specified at command line,
>> according to code it takes "/usr/src" as default. Do you have a
>> stale/old rc.conf(5) file in there, /usr/src/etc/defaults/rc.conf?
>
> I have the CVS checkout there that wa
"Izumi Tsutsui"
writes:
> Module Name: src
> Committed By: tsutsui
> Date: Tue Jun 5 13:20:01 UTC 2012
>
> Modified Files:
> src/etc: MAKEDEV.tmpl
>
> Log Message:
> Invoke MAKEDEV.local via $HOST_SH (default ${HOST_SH:=sh}) instead of
> hardcoded "sh" to avoid unexpected errors o
On Tue, Jun 05, 2012 at 10:18:28PM +0400, Aleksej Saushev wrote:
> > +++ src/etc/MAKEDEV.tmplTue Jun 5 13:20:01 2012
> > @@ -2092,9 +2093,9 @@ local)
> > umask 0
> > if [ -n "$count_nodes" ]; then
> > count_nodes=$((count_nodes + \
> > -
On Tue, 05 Jun 2012, Aleksej Saushev wrote:
if [ -n "$count_nodes" ]; then
count_nodes=$((count_nodes + \
- $(linecount "$(sh "$0.local" $opts -s all)") ))
+ $(linecount "$("$HOST_SH" "$0.local" $opts -s
On Nov 24, 8:30am, "Reinoud Zandijk" wrote:
}
} Module Name: src
} Committed By: reinoud
} Date: Wed Jul 4 13:54:20 UTC 2012
}
} Modified Files:
} src/etc/etc.amd64: Makefile.inc
} src/etc/etc.i386: Makefile.inc
}
} Log Message:
} Disable GENERIC_USERMODE kernel auto-build
"Julian Fagir" writes:
> Module Name: src
> Committed By: jdf
> Date: Mon Jul 30 22:13:38 UTC 2012
>
> Modified Files:
> src/etc: daily
>
> Log Message:
> Call `makemandb -q` instead of `makemandb`, as proposed by Edgar Fuss on
> tech-userlevel on 20th of July 2012, 12:38.
Why doe
On Thu, Aug 02, 2012 at 02:01:22AM +0400, Aleksej Saushev wrote:
> "Julian Fagir" writes:
>
> > Module Name:src
> > Committed By: jdf
> > Date: Mon Jul 30 22:13:38 UTC 2012
> >
> > Modified Files:
> > src/etc: daily
> >
> > Log Message:
> > Call `makemandb -q` inst
martin@ wrote:
> Module Name: src
> Committed By: martin
> Date: Wed Sep 5 08:25:54 UTC 2012
>
> Modified Files:
> src/etc: MAKEDEV.tmpl
>
> Log Message:
> Make the "init" target create optys as well - those were removed from "all",
> but we still need them in emergency setups an
On Fri, Sep 07, 2012 at 03:05:16AM +0900, Izumi Tsutsui wrote:
> Isn't it easier to add "ipty" into MI "all" target (at least for HEAD)?
Easier maybe, but we do not realy want those device nodes on typical /dev
filesystems (at least that was my understanding).
> We had to fix src/distrib/sparc/mi
> > Module Name:src
> > Committed By: martin
> > Date: Wed Sep 5 08:25:54 UTC 2012
> >
> > Modified Files:
> > src/etc: MAKEDEV.tmpl
> >
> > Log Message:
> > Make the "init" target create optys as well - those were removed from "all",
> > but we still need them i
martin@ wrote:
> On Fri, Sep 07, 2012 at 03:05:16AM +0900, Izumi Tsutsui wrote:
> > Isn't it easier to add "ipty" into MI "all" target (at least for HEAD)?
>
> Easier maybe, but we do not realy want those device nodes on typical /dev
> filesystems (at least that was my understanding).
- What's t
On Fri, Sep 07, 2012 at 09:20:49PM +0900, Izumi Tsutsui wrote:
> - What's the actual benefits on removing those device nodes on /dev?
> Is it more important than possible fallouts in install materials?
Those nodes, if used together with ptyfs, create a serious security
risk. That is why we remov
martin@ wrote:
> On Fri, Sep 07, 2012 at 09:20:49PM +0900, Izumi Tsutsui wrote:
> > - What's the actual benefits on removing those device nodes on /dev?
> > Is it more important than possible fallouts in install materials?
>
> Those nodes, if used together with ptyfs, create a serious security
On Sep 7, 9:20pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/etc
| > Easier maybe, but we do not realy want those device nodes on typical /dev
| > filesystems (at least that was my understanding).
|
| - What's the actual benefits on removing t
christos@ wrote:
> | - If we are going to remove compat pty nodes completely,
> | why don't we also update all install stuff not implicitly
> | using those node, i.e. shouldn't we change all install media
> | to have mount_ptyfs(8) and explicitly mount /dev/pts in /.profile
> | or /etc/rc
On Sat, Sep 08, 2012 at 12:24:21AM +0900, Izumi Tsutsui wrote:
> x86's MAKEDEV scripts still have ipty in all_md and my freshly
> installed NetBSD/i386 6.0_RC1 still has /dev/[pt]typ[01] nodes.
> Should it be fixed even in netbsd-6?
Yes!
> (in that case we should also fix installimage script to u
martin@ wrote:
> > (in that case we should also fix installimage script to use ptyfs though)
>
> If you could do that, it would be great.
I guess adding
>> mount -t ptyfs ptyfs /dev/pts
line into src/distrib/{amd64,i386}/installimage/etc.rc
around mount -t tmpfs is enough, but I have not confirm
On Fri, Sep 07, 2012 at 09:45:09AM -0400, Christos Zoulas wrote:
> On Sep 7, 9:20pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> -- Subject: Re: CVS commit: src/etc
>
> | > Easier maybe, but we do not realy want those device nodes on typical /dev
> | > filesystems
On Sat, Sep 08, 2012 at 01:34:37AM +0900, Izumi Tsutsui wrote:
> Probably we should also remove ipty from MAKEDEV "init" target
> and also add the above "mount -t ptyfs ..." line into
> src/distrib/{amd64,i386}/cdroms/etc.rc and
> src/distrib/sparc64/cdroms/installcd/etc.rc
> because third party li
martin@ wrote:
> On Sat, Sep 08, 2012 at 01:34:37AM +0900, Izumi Tsutsui wrote:
> > Probably we should also remove ipty from MAKEDEV "init" target
> > and also add the above "mount -t ptyfs ..." line into
> > src/distrib/{amd64,i386}/cdroms/etc.rc and
> > src/distrib/sparc64/cdroms/installcd/etc.r
In article <120908030745.m0127...@mirage.ceres.dti.ne.jp>,
Izumi Tsutsui wrote:
>martin@ wrote:
>
>> On Sat, Sep 08, 2012 at 01:34:37AM +0900, Izumi Tsutsui wrote:
>> > Probably we should also remove ipty from MAKEDEV "init" target
>> > and also add the above "mount -t ptyfs ..." line into
>> > s
christos@ wrote:
> >> We can, however, use a modified MAKEDEV script for install cdroms (and then
> >> use ptyfs).
> >
> >MAKEDEV is a generated file so I'm afraid it is a bit annoying
> >to sync modified version with standard one.
>
> but MAKEDEV can just run mkdir /dev/pts, the rest can be done
On Sep 8, 9:31am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/etc
| christos@ wrote:
|
| > >> We can, however, use a modified MAKEDEV script for install cdroms (and
then
| > >> use ptyfs).
| > >
| > >MAKEDEV is a generated
christos@ wrote:
> I am all for removing the ipty and opty targets (and COMPAT_BSDPTY) and
> making everything use ptyfs.
For HEAD, yes. What for netbsd-6 and 6.0-RELEASE?
---
Izumi Tsutsui
On Sep 8, 12:33pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/etc
| christos@ wrote:
|
| > I am all for removing the ipty and opty targets (and COMPAT_BSDPTY) and
| > making everything use ptyfs.
|
| For HEAD, yes. What for netbsd-6 and 6.0-RELEASE?
I
martin@ wrote:
> On Sat, Sep 08, 2012 at 01:34:37AM +0900, Izumi Tsutsui wrote:
> > Probably we should also remove ipty from MAKEDEV "init" target
> > and also add the above "mount -t ptyfs ..." line into
> > src/distrib/{amd64,i386}/cdroms/etc.rc and
> > src/distrib/sparc64/cdroms/installcd/etc.r
On Sat, Sep 08, 2012 at 01:59:14AM -0400, Christos Zoulas wrote:
> I think we have to keep using ipty and opty. It is less risky.
I agree. I would suggest to modify the pending pullup #543 with a
patch (basically s/opty/ipty/) and be done for -6 with it.
Then lets start the "big" revamp for all i
martin@ wrote:
> On Sat, Sep 08, 2012 at 01:59:14AM -0400, Christos Zoulas wrote:
> > I think we have to keep using ipty and opty. It is less risky.
>
> I agree. I would suggest to modify the pending pullup #543 with a
> patch (basically s/opty/ipty/) and be done for -6 with it.
If "ipty" entrie
On Sep 8, 2:39pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/etc
| On Sat, Sep 08, 2012 at 01:59:14AM -0400, Christos Zoulas wrote:
| > I think we have to keep using ipty and opty. It is less risky.
|
| I agree. I would suggest to modify the pending pullup #
On Sat, Sep 08, 2012 at 10:03:01PM +0900, Izumi Tsutsui wrote:
> It would be better to start it after we get some RC2 feedback?
You mean for -current?
We need to process #543 (or a variation of it) to fix the sparc64 install
CDs.
Martin
martin@ wrote:
> On Sat, Sep 08, 2012 at 10:03:01PM +0900, Izumi Tsutsui wrote:
> > It would be better to start it after we get some RC2 feedback?
>
> You mean for -current?
Yes, I meant "the big revamp for all install media in -current" after RC2.
> We need to process #543 (or a variation of i
Here is a patch that changes MAKEDEV to:
- not include "{i,o,}pty" on any arch in the "all" target
- mount a ptyfs on top of a tmpfs /dev if the latter is created and
populated due to missing /dev/console by init
Since our ptyfs implementation currently only allows a single instance, this
ca
On Sep 14, 5:23pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/etc
| Here is a patch that changes MAKEDEV to:
|
| - not include "{i,o,}pty" on any arch in the "all" target
| - mount a ptyfs on top of a tmpfs /dev if the latter is created an
martin@ wrote:
> Here is a patch that changes MAKEDEV to:
>
> - not include "{i,o,}pty" on any arch in the "all" target
> - mount a ptyfs on top of a tmpfs /dev if the latter is created and
>populated due to missing /dev/console by init
>
> Since our ptyfs implementation currently only all
On Fri, 14 Sep 2012, Martin Husemann wrote:
Here is a patch that changes MAKEDEV to:
- not include "{i,o,}pty" on any arch in the "all" target
- mount a ptyfs on top of a tmpfs /dev if the latter is created and
populated due to missing /dev/console by init
Under what circumstances is it usef
On Sat, Sep 15, 2012 at 12:35:26PM +0200, Alan Barrett wrote:
> Under what circumstances is it useful for MAKEDEV to mount ptyfs?
> Why can't we rely on other code to mount it later?
We can - this is just a very central place to catch them all easily.
I don't mind doing it explicitly elsewehere.
On Sat, Sep 15, 2012 at 04:26:12PM +0900, Izumi Tsutsui wrote:
> - MAKEDEV already has "makedir" command so isn't it better to use
> "makedir pts 755" as "ptm" entry does? Or just do "mkdev ptm"?
Yes, that is better.
> - isn't it better to fallback to create compat ipty nodes
> if mount_ptyfs
martin@ wrote:
> > - isn't it better to fallback to create compat ipty nodes
> > if mount_ptyfs fails, so that we don't have to put tweaks into
> > obsolete install floppies?
> > (though it might cause inode shortage because a number of nodes is
> >calculated before create_mfs_dev is cal
On Sat, 15 Sep 2012, Martin Husemann wrote:
On Sat, Sep 15, 2012 at 12:35:26PM +0200, Alan Barrett wrote:
Under what circumstances is it useful for MAKEDEV to mount
ptyfs? Why can't we rely on other code to mount it later?
We can - this is just a very central place to catch them all
easily.
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 quer
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,
Alan Barrett 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 th
On Jan 8, 2014, at 10:25 , Greg Troxel 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
On Sat, 11 Jan 2014, Erik Fair wrote:
On Jan 8, 2014, at 10:25 , Greg Troxel 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
[ 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 moun
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
>
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
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
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 wh
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 doe
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
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 moun
On Fri, 10 Jul 2009, Christos Zoulas wrote:
> Index: src/etc/rc.d/fsck_root
> - *:/:*) break
> + *:/:*) case "${fs_spec}" in
> + *:*)
> + echo "Not checking /: nfs mounted"
> + return
> +
In message: <20090711120215.gb1...@apb-laptoy.apb.alt.za>
Alan Barrett writes:
: On Fri, 10 Jul 2009, Christos Zoulas wrote:
: > Index: src/etc/rc.d/fsck_root
: > - *:/:*) break
: > + *:/:*) case "${fs_spec}" in
: > + *:*)
: > +
Module Name: src
Committed By:christos
Date:Thu Sep 24 14:53:36 UTC 2009
Modified Files:
src/etc: MAKEDEV.tmpl
Log Message:
fix dri/drm confusiog
thanks.
.mrg.
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
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 '$' pr
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
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
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
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
> 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
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 s
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 lega
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"..
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 a
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
> 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 leg
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 littl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18.01.2016 00:18, Christos Zoulas wrote:
> Module Name: src Committed By: christos Date: Sun Jan 17
> 23:18:19
> UTC 2016
>
> Modified Files: src/etc: MAKEDEV.tmpl
>
> Log Message: Add /dev/full
>
Thank you! this is useful in
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 vrr
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 retrie
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 whi
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 M
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-ind
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
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 so
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 so
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 t
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
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
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.
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 su
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
> 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.
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
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
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 di
1 - 100 of 260 matches
Mail list logo
