off by default.
o Apparently the routine displaying the informational messages wasn't
checking its knob in rc.conf, so fix that as well.
Requested by: obrien
devfs(8) rules in rc(8). It is most useful for applying
rules to devfs(5) mount points in /dev or inside jails.
The following line of script is sufficient to
mount a relatively useful+secure devfs(5) in a jail:
devfs_mount_jail /some/jail/dev
Some new shell routines available to scripts that source
rc.subr(5):
o devfs_link - Makes it a little easier to create symlinks
o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules
o devfs_set_ruleset - Set a ruleset to a devfs(5) mount
o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount
o devfs_domount - Mount devfs(5) and apply some ruleset
o devfs_mount_jail - Mount devfs(5) and apply a ruleset
appropriate to jails.
Additional rulesets can be specified in /etc/devfs.rules.
If the devfs_system_ruleset variable is defined in rc.conf
and it contains the name of a ruleset defined in /etc/defaults/devfs.rules
or user supplied rulesets in /etc/devfs.rules then that ruleset will
be applied to /dev at startup by the /etc/rc.d/devfs script. It can
also be applied post-startup:
/etc/rc.d/devfs start
This is a more flexible mechanism than the previous method of using
/etc/devfs.conf. However, that method is still available.
Note: since devfs(8) doesn't provide any way for creating symlinks
as part of a ruleset, anyone wishing to create symlinks in a devfs(5)
as part of the bootup sequence will still have to rely on /etc/devfs.conf.
evaluating the $_precmd command as a string. We're not actually
trying to evaluate the contents of the command.
Reported by: Glenn Johnson <gjohnson@srrc.ars.usda.gov>
exception of the default 'status' command) regardless of whether the
executed command was actually successfull or not. Forced scripts should
always correctly reflect the outcome of the command.
NOTE: exit values are treated as booleans. We don't care what
the actual exit value was, only whether it was successfull or not.
take advantage of the rc.subr(8) glue. They are renamed dhclient_program
and dhclient_flags.
o Rename them in rc.conf(5)
o Rename them in /etc/defaults/rc.conf
o Add the deprecated variables to /etc/rc.subr
o Isolate the use of the 'command' variable to the
NetBSD specific parts in /etc/rc.d/dhclient.
o Now that dhcp_flags has also been renamed it will
be applied properly by rc.subr(8) glue code.
Reported by: John Nielsen <john@jnielsen.net>
Fix a minor grammer nit.
Get rid of _echo that uses logger and just call logger in the 3 routines
that need it.
Add a comment referencing rc.conf(5) in the case of an incorrectly set
variable.
This pulls rc.subr up to 1.51 of rc.subr. I skipped 1.49 (systrace support)
since I don't have systrace.
Obtained from: NetBSD
all instances of `${CMD_OSTYPE}` to just using ${OSTYPE}. This saves us a
shell invocation on anything that is OS-dependent. I seriously doubt that we
will be spontaneously changing OS types during bootup.
xntpd_* -> ntpd_*
portmap_* -> rpcbind_*
Also change single_mountd_enable to mountd_enable.
We also include shims for all the old variable names.
Submitted by: Mike Makonnen <makonnen@pacbell.net>
