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/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/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/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/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/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/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
  }
  
  
 

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

[Marc Balmer]

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?

 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.13 -r1.14 src/etc/rc.d/ntpd
 cvs rdiff -u -r1.8 -r1.9 src/etc/rc.d/ppp
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 
 Modified files:
 
 Index: src/etc/rc.d/ntpd
 diff -u src/etc/rc.d/ntpd:1.13 src/etc/rc.d/ntpd:1.14
 --- src/etc/rc.d/ntpd:1.13Fri Aug 13 18:08:03 2004
 +++ src/etc/rc.d/ntpd Tue Dec  4 16:38:40 2012
 @@ -1,6 +1,6 @@
 #!/bin/sh
 #
 -# $NetBSD: ntpd,v 1.13 2004/08/13 18:08:03 mycroft Exp $
 +# $NetBSD: ntpd,v 1.14 2012/12/04 16:38:40 prlw1 Exp $
 #
 
 # PROVIDE: ntpd
 @@ -19,6 +19,7 @@ required_files=/etc/ntp.conf
 
 ntpd_precmd()
 {
 + rc_flags=-p ${pidfile} $rc_flags
   if [ -z $ntpd_chrootdir ]; then
   return 0;
   fi
 
 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.8  Mon Oct 11 15:00:51 2004
 +++ src/etc/rc.d/ppp  Tue 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
 }
 
 


Freundliche Grüsse,
micro systems

Marc Balmer

--
Marc Balmer
micro systems, Wiesendamm 2a, Postfach, 4019 Basel
fon +41 61 383 05 10, fax +41 61 383 05 12, http://www.msys.ch/

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

[Tetsuya Isaki]

At Wed, 13 Jun 2012 11:35:37 +0900,
Tetsuya Isaki wrote:
 The rcvar assignment was missing, but shouldn't the normal logic
skip calling the start command if the rcvar is not YES?
   
   Ah, you mean it's enough to add
rcvar=${name}
   line into rc.d/makemandb instead of checkyesno?
  
  Exactly.
 
 Is it true?
 I could not disable it with this patch (diff from rev1.1):
 Please show the precise patch which you suggest.

I am sorry, I confirmed that it works.

Then, May I revert my rev 1.2 (to a state of rev 1.1) and
re-commit it (as rev 1.4) to simplify pulling up?
or commit it (as rev 1.3) and pull up 1.2 and 1.3?
---
Tetsuya Isaki is...@pastel-flower.jp / is...@netbsd.org

 
 --- makemandb.ORG 2012-03-11 13:27:21.0 +0900
 +++ makemandb 2012-06-13 10:35:22.0 +0900
 @@ -10,6 +10,7 @@
  $_rc_subr_loaded . /etc/rc.subr
  
  name=makemandb
 +rcvar=$name
  required_files=/etc/man.conf /usr/sbin/makemandb
  start_cmd=makemandb_start
  stop_cmd=:
 
 ---
 Tetsuya Isaki is...@pastel-flower.jp / is...@netbsd.org
 

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

[Joerg Sonnenberger]

On Sat, Jun 16, 2012 at 10:50:08AM +0900, Tetsuya Isaki wrote:
 At Wed, 13 Jun 2012 11:35:37 +0900,
 Tetsuya Isaki wrote:
  The rcvar assignment was missing, but shouldn't the normal logic
 skip calling the start command if the rcvar is not YES?

Ah, you mean it's enough to add
 rcvar=${name}
line into rc.d/makemandb instead of checkyesno?
   
   Exactly.
  
  Is it true?
  I could not disable it with this patch (diff from rev1.1):
  Please show the precise patch which you suggest.
 
 I am sorry, I confirmed that it works.
 
 Then, May I revert my rev 1.2 (to a state of rev 1.1) and
 re-commit it (as rev 1.4) to simplify pulling up?
 or commit it (as rev 1.3) and pull up 1.2 and 1.3?

Just requestion pullup of 1.2 and 1.3 at the same time.
Thanks for looking at this in detail.

Joerg

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

[Joerg Sonnenberger]

On Tue, Jun 12, 2012 at 11:34:49PM +0900, Izumi Tsutsui wrote:
 joerg@ wrote:
 
  On Tue, Jun 12, 2012 at 10:59:34PM +0900, Izumi Tsutsui wrote:
   joerg@ wrote:
   
 Modified Files:
   src/etc/rc.d: makemandb
 
 Log Message:
 Allows you to disable it if makemandb=NO in rc.conf.
 Thanks tsutsui@ and Yasushi Oshima.

Is the manual checkyesno really needed?
   
   It's too slow and annoying on non modern x86 machines as fccache.
   Isn't it the reason why you added makemandb=YES in 
   src/etc/defaults/rc.conf?
  
  It should just run stat on all entries in /usr/share/man etc and be
  done. So it shouldn't be that bad even on slow hardware after the first
  run. The rcvar assignment was missing, but shouldn't the normal logic
  skip calling the start command if the rcvar is not YES?
 
 Ah, you mean it's enough to add
  rcvar=${name}
 line into rc.d/makemandb instead of checkyesno?

Exactly.

Joerg

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

[Izumi Tsutsui]

joerg@ wrote:

 On Tue, Jun 12, 2012 at 10:59:34PM +0900, Izumi Tsutsui wrote:
  joerg@ wrote:
  
Modified Files:
src/etc/rc.d: makemandb

Log Message:
Allows you to disable it if makemandb=NO in rc.conf.
Thanks tsutsui@ and Yasushi Oshima.
   
   Is the manual checkyesno really needed?
  
  It's too slow and annoying on non modern x86 machines as fccache.
  Isn't it the reason why you added makemandb=YES in src/etc/defaults/rc.conf?
 
 It should just run stat on all entries in /usr/share/man etc and be
 done. So it shouldn't be that bad even on slow hardware after the first
 run. The rcvar assignment was missing, but shouldn't the normal logic
 skip calling the start command if the rcvar is not YES?

Ah, you mean it's enough to add
 rcvar=${name}
line into rc.d/makemandb instead of checkyesno?

---
Izumi Tsutsui

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

[Matthias Scheler]

On Sun, Jan 09, 2011 at 02:47:27AM +, David Holland wrote:
 On Sat, Jan 08, 2011 at 11:49:54PM +, Matthias Scheler wrote:
This is no longer true, for lvm and other things, so let's take a deep
breath and move chown.
   
   Yes, but we should probably provide a symlink from
   /usr/sbin/chown to /sbin/chown for backwards compatibility
   reasons.
 
 Maybe for a while, but I hope not permanently...

It's been in /usr/sbin for almost 18 years. And the symlink doesn't
really hurt.

Kind regards

-- 
Matthias Scheler  http://zhadum.org.uk/

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

[David Holland]

On Sat, Jan 08, 2011 at 04:16:52PM +, Adam Hamsik wrote:
  Modified Files:
   src/etc/rc.d: mountcritlocal
  
  Log Message:
  Use /rescue/chown not chown from /usr/sbin which might not be available in
  time of running this script.
  
  XXX. Why is chown in /usr/sbin ? it should be moved to /sbin

Because historically nothing needed to be chowned during boot because
it was all root.

This is no longer true, for lvm and other things, so let's take a deep
breath and move chown. I don't like the idea of having rc.d scripts
depend on /rescue.

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

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

[Matthias Scheler]

On 8 Jan 2011, at 23:21, David Holland wrote:
 This is no longer true, for lvm and other things, so let's take a deep
 breath and move chown.

Yes, but we should probably provide a symlink from /usr/sbin/chown to 
/sbin/chown for backwards compatibility reasons.

 I don't like the idea of having rc.d scripts depend on /rescue.

Me neither.

Kind regards

-- 
Matthias Scheler   http://zhadum.org.uk/

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

[David Holland]

On Sat, Jan 08, 2011 at 11:49:54PM +, Matthias Scheler wrote:
   This is no longer true, for lvm and other things, so let's take a deep
   breath and move chown.
  
  Yes, but we should probably provide a symlink from
  /usr/sbin/chown to /sbin/chown for backwards compatibility
  reasons.

Maybe for a while, but I hope not permanently...

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

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

[Hubert Feyrer]

On Sat, 8 Jan 2011, David Holland wrote:

 XXX. Why is chown in /usr/sbin ? it should be moved to /sbin

Because historically nothing needed to be chowned during boot because
it was all root.

This is no longer true, for lvm and other things, so let's take a deep
breath and move chown. I don't like the idea of having rc.d scripts
depend on /rescue.


Seconded (on the don't depend on /rescue part).
FWIW:
fehu.org% cat /etc/debian_version
squeeze/sid
fehu.org% which chown
/bin/chown


 - Hubert

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

[Alan Barrett]

On Tue, 16 Feb 2010, matthew green wrote:
 Modified Files:
   src/etc/rc.d: fsck_root
 
 Log Message:
 only fsck / if we find it in /etc/fstab.  diskless systems don't need
 a / entry.

This seems reasonable.  But, without this patch, would it work to
place from_mount in the fs_spec column, and 0 in the fs_passno
column?

fs_spec=from_mount seems to be documented only in the mount(8)
man page, not in fstab(5).

--apb (Alan Barrett)

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

[matthew green]

   On Tue, 16 Feb 2010, matthew green wrote:
Modified Files:
   src/etc/rc.d: fsck_root

Log Message:
only fsck / if we find it in /etc/fstab.  diskless systems don't need
a / entry.
   
   This seems reasonable.  But, without this patch, would it work to
   place from_mount in the fs_spec column, and 0 in the fs_passno
   column?
   
   fs_spec=from_mount seems to be documented only in the mount(8)
   man page, not in fstab(5).

hmmm, interesting idea.  initially i didn't realise that you meant for
from_mount to be a literal string.

that would also fix the mount / problem in rc.d/root.


.mrg.

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

[Marc Balmer]

Am 16.02.10 03:46, schrieb matthew green:

Module Name:src
Committed By:   mrg
Date:   Tue Feb 16 02:46:02 UTC 2010

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

Log Message:
only fsck / if we find it in /etc/fstab.  diskless systems don't need
a / entry.

XXX: still get an error from mount / in etc/rc.d/root itself.


There is a corner case that will now use an unchecked filesystem:  When 
you specify it during boot on the console.


Not sure if that is a real problem, though.

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

[Alan Barrett]

On Mon, 05 Oct 2009, Adam Hamsik wrote:
 Modified Files:
   src/etc/rc.d: mountall
 
 Log Message:
 Add support for mounting zfs filesystems to mountall script. ZFS configuration
 is stored in /etc/zpool.cache and it is automatically loaded to kernel from
 filesystem. Filesystems are then configured accordingly to their properties
 loaded from cache file.

Is /etc/zpool.cache a human-edited configuration file (in which
case, why the .cache name?), or is it a machine-readable database (in
which case, why is it in /etc?), or is it something else?

--apb (Alan Barrett)

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

[Adam Hamsik]

Hi,
On Oct,Tuesday 6 2009, at 9:03 AM, Alan Barrett wrote:


On Mon, 05 Oct 2009, Adam Hamsik wrote:

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

Log Message:
Add support for mounting zfs filesystems to mountall script. ZFS  
configuration
is stored in /etc/zpool.cache and it is automatically loaded to  
kernel from
filesystem. Filesystems are then configured accordingly to their  
properties

loaded from cache file.


Is /etc/zpool.cache a human-edited configuration file (in which
case, why the .cache name?), or is it a machine-readable database  
(in

which case, why is it in /etc?), or is it something else?


It is a binary file. Something like binary plist. Do you have any  
better place for it ? I think that we should keep it in etc until we  
start work on a zfs on root support then we will need to move it some  
where else anyway.


Regards

Adam.

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

[Jason Thorpe]

On Oct 6, 2009, at 1:22 AM, Adam Hamsik wrote:

 Hi,
 On Oct,Tuesday 6 2009, at 9:03 AM, Alan Barrett wrote:
 
 On Mon, 05 Oct 2009, Adam Hamsik wrote:
 Modified Files:
 src/etc/rc.d: mountall
 
 Log Message:
 Add support for mounting zfs filesystems to mountall script. ZFS 
 configuration
 is stored in /etc/zpool.cache and it is automatically loaded to kernel from
 filesystem. Filesystems are then configured accordingly to their properties
 loaded from cache file.
 
 Is /etc/zpool.cache a human-edited configuration file (in which
 case, why the .cache name?), or is it a machine-readable database (in
 which case, why is it in /etc?), or is it something else?
 
 It is a binary file. Something like binary plist. Do you have any better 
 place for it ? I think that we should keep it in etc until we start work on a 
 zfs on root support then we will need to move it some where else anyway.

It belongs in /var/db ... but I'd like to ask why you need it at all?

 
 Regards
 
 Adam.

-- thorpej

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

[Alan Barrett]

On Thu, 10 Sep 2009, Erik Fair wrote:
 On Sep 8, 2009, at 01:56, Christoph Egger wrote:
 Modified Files:
  src/etc/rc.d: network
 
 Log Message:
 Do not flush routes if root file system is nfs mounted.
 Fixes boot problem when the nfs server is in a different subnet.
 
 This change should be pulled up to netbsd-5.

No, this change should be backed out, and the real problem (incorrect
default for flushroutes) addressed in a different way.

--apb (Alan Barrett)

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

[matthew green]

   On Thu, 10 Sep 2009, Erik Fair wrote:
On Sep 8, 2009, at 01:56, Christoph Egger wrote:
Modified Files:
  src/etc/rc.d: network

Log Message:
Do not flush routes if root file system is nfs mounted.
Fixes boot problem when the nfs server is in a different subnet.

This change should be pulled up to netbsd-5.
   
   No, this change should be backed out, and the real problem (incorrect
   default for flushroutes) addressed in a different way.


i agree.

this is the 2nd time in recent history that controversial
changes to rc.d have been commited without discussion.

this needs to stop.


.mrg.

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

[Christoph Egger]

matthew green wrote:
On Thu, 10 Sep 2009, Erik Fair wrote:
 On Sep 8, 2009, at 01:56, Christoph Egger wrote:
 Modified Files:
 src/etc/rc.d: network
 
 Log Message:
 Do not flush routes if root file system is nfs mounted.
 Fixes boot problem when the nfs server is in a different subnet.
 
 This change should be pulled up to netbsd-5.

No, this change should be backed out, and the real problem (incorrect
default for flushroutes) addressed in a different way.
 
 
 i agree.
 
 this is the 2nd time in recent history that controversial
 changes to rc.d have been commited without discussion.

recent history has shown that patches got discussed after commit
not before.

Christoph

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

[Quentin Garnier]

On Fri, Sep 11, 2009 at 11:26:54PM +0200, Christoph Egger wrote:
 matthew green wrote:
 On Thu, 10 Sep 2009, Erik Fair wrote:
  On Sep 8, 2009, at 01:56, Christoph Egger wrote:
  Modified Files:
src/etc/rc.d: network
  
  Log Message:
  Do not flush routes if root file system is nfs mounted.
  Fixes boot problem when the nfs server is in a different subnet.
  
  This change should be pulled up to netbsd-5.
 
 No, this change should be backed out, and the real problem (incorrect
 default for flushroutes) addressed in a different way.
  
  
  i agree.
  
  this is the 2nd time in recent history that controversial
  changes to rc.d have been commited without discussion.
 
 recent history has shown that patches got discussed after commit
 not before.

Recent history has shown that you're not a stranger to committing
convenience workarounds and then freely admitting that you have no
complete grasp of the issue at hand.

I'm not sure you want to continue on that slope.

-- 
Quentin Garnier - c...@cubidou.net - c...@netbsd.org
See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.


pgpNFiyiFpYae.pgp
Description: PGP signature

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

[Izumi Tsutsui]

christoph_eg...@gmx.de wrote:

 recent history has shown that patches got discussed after commit
 not before.

The history has also shown you put too much botches ;-p
---
Izumi Tsutsui

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

[Erik Fair]

On Sep 8, 2009, at 01:56, Christoph Egger wrote:


Module Name:src
Committed By:   cegger
Date:   Tue Sep  8 08:56:34 UTC 2009

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

Log Message:
Do not flush routes if root file system is nfs mounted.
Fixes boot problem when the nfs server is in a different subnet.


To generate a diff of this commit:
cvs rdiff -u -r1.58 -r1.59 src/etc/rc.d/network

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



This change should be pulled up to netbsd-5.

Erik f...@netbsd.org

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

[Joerg Sonnenberger]

On Tue, Sep 08, 2009 at 06:07:57PM +0200, Christoph Egger wrote:
 Joerg Sonnenberger wrote:
  On Tue, Sep 08, 2009 at 02:30:56PM +0200, Christoph Egger wrote:
  Perhaps a better test would be that dhcpcd shouldn't touch
  the default route unless the default route is through the
  interface that dhcpcd is managing.
  I agree.
  How should dhcpcd deal with /etc/resolv.conf ?
  If dhcpcd removes and rewrites the entries, DNS queries in-between
  may fail (i.e. mounting nfs)
  
  I would say you have a completely broken setup in that case. You can
  easily prevent dhcpcd from changing the default route at all if you need
  to.
 
 I tried dhcpcd -n -p if but I ended up with having the nfs server
 unreachable.

You haven't included -G to keep the default route.

Joerg

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

[Christoph Egger]

Joerg Sonnenberger wrote:
 On Tue, Sep 08, 2009 at 02:30:56PM +0200, Christoph Egger wrote:
 Perhaps a better test would be that dhcpcd shouldn't touch
 the default route unless the default route is through the
 interface that dhcpcd is managing.
 I agree.
 How should dhcpcd deal with /etc/resolv.conf ?
 If dhcpcd removes and rewrites the entries, DNS queries in-between
 may fail (i.e. mounting nfs)
 
 I would say you have a completely broken setup in that case. You can
 easily prevent dhcpcd from changing the default route at all if you need
 to.

I tried dhcpcd -n -p if but I ended up with having the nfs server
unreachable.

Christoph

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

[Jason Thorpe]

On Aug 3, 2009, at 10:45 AM, Perry E. Metzger wrote:


Module Name:src
Committed By:   perry
Date:   Mon Aug  3 17:45:48 UTC 2009

Modified Files:
src/etc/rc.d: named ntpdate

Log Message:
ntpdate can't work without named because a modern ntp.conf has dns
names in it. We therefore now depend on it.

However, this would have then created a circular dependency because  
named

depended on SERVERS, and racoon was before SERVERS and required kdc,
and kdc needs the time to be right and thus depended on ntp.

Instead, have named depend on NETWORKING (so that there is a network
there), mountcritremote (so we know that named has a directory to work
from) and syslogd (so that named has some place to spew information).

I'm not sure this is perfect, but it is certainly a big improvement
over constantly failing ntpdate runs during boot.


Definitely not perfect .. named might also depend on ntp (by way of  
kdc) if GSS-TSIG is enabled.


Explicit dependencies are the pits.  Launch on demand is the way to go.

-- thorpej

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

[David Holland]

On Thu, May 14, 2009 at 03:33:36PM +, Roy Marples wrote:
  Module Name: src
  Committed By:roy
  Date:Thu May 14 15:33:36 UTC 2009
  
  Modified Files:
   src/etc/rc.d: network
  
  Log Message:
  Only start dhcpcd per interface if not running the full dhcpcd daemon.
  Only stop dhcpcd pre interface if it's running for the interface.
  
  Fixes PR bin/4030


Don't think that's right :-)

I fixed gnats, you may want to fix the commit message in CVS.

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

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

[Roy Marples]

David Holland wrote:

On Thu, May 14, 2009 at 03:33:36PM +, Roy Marples wrote:
  Module Name:  src
  Committed By: roy
  Date: Thu May 14 15:33:36 UTC 2009
  
  Modified Files:

src/etc/rc.d: network
  
  Log Message:

  Only start dhcpcd per interface if not running the full dhcpcd daemon.
  Only stop dhcpcd pre interface if it's running for the interface.
  
  Fixes PR bin/4030



Don't think that's right :-)

I fixed gnats, you may want to fix the commit message in CVS.


D'oh - it's bin/40320
D'oh - mailed to source-changes, not source-changes-d

cvs admin is dumping core on me trying to change the commit message :/

Thanks

Roy

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

[Christos Zoulas]

In article 87k55c4jkd@snark.cb.piermont.com,
Perry E. Metzger pe...@piermont.com wrote:

Christos Zoulas chris...@netbsd.org writes:
 Module Name: src
 Committed By:christos
 Date:Wed Apr 22 18:27:03 UTC 2009

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

 Log Message:
 Adjust for new default location of the pid file.

Seems kind of weird to have stuff in /var/run/named/named.pid -- what's
the point?

2486.   [func]  The default locations for named.pid and lwresd.pid
are now /var/run/named/named.pid and
/var/run/lwresd/lwresd.pid respectively.

This allows the owner of the containing directory
to be set, for named -u support, and allows there
to be a permanent symbolic link in the path, for
named -t support.  [RT #18306]

christos

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

[Paul Goyette]

It started for me on Saturday, when I updated from 5.99.8 to 5.99.11

On Tue, 21 Apr 2009, Thomas Klausner wrote:


On Mon, Apr 13, 2009 at 06:48:15PM +, Adam Hamsik wrote:

Module Name:src
Committed By:   haad
Date:   Mon Apr 13 18:48:15 UTC 2009

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

Log Message:
We need writable /dev to get lvm working otherwise lvm devices can't be created.


I don't know when this was introduced, but I just saw this:
About to run shutdown hooks...
rcorder: Circular dependency on provision `root' in file `/etc/rc.d/lvm'.

Thomas



-
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:  |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-

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

[Adam Hamsik]

On Apr,Tuesday 21 2009, at 5:46 PM, Paul Goyette wrote:


It started for me on Saturday, when I updated from 5.99.8 to 5.99.11


This should be fixed now.

Regards

Adam.