thin blue air if the kenv doesn't have any info.
This improves the truth value of the comment above significantly and
reduces the bogous output on the console considerably.
- Use a more robust check to determine if we need to load ipl.ko.
- Don't try to run ipf -E if ipfilter is already enabled. Look at
the net.inet.ipf.fr_running sysctl to figure this out. This fixes
a warning message about ipfilter being already initialized.
- Only one ipf -E command is needed. We don't need an extra one for
the -6 case which would only print a warning message about ipfilter
being already initialized.
- Fix one occurence where we were running /sbin/ipf directly without
using the ${ipfilter_program} variable if set.
- In ipfilter_stop(), don't try to save the firewall state tables if
ipfilter is disabled. Similarly, don't try to disable it if it's
already disabled. This fixes some more error messages.
and use it in src/etc/sendmail/Makefile in case the user wants to use
a different path to the sendmail m4 sources (e.g., sendmail port users).
Submitted by: dinoex
MFC after: 21 days
X-MFC after: RELENG_4 code freeze ends
dhclient couldn't get killed.
If we execute 'dhclient -r', dhclient gets already
killed, so there is no need to do it twice. Only do
this if we really have to release some leases.
Reviewed by: silence on freebsd-rc@yahoogroups.com
written by Stuart Walsh and Duncan Barclay (with some kibbitzing by
me). I'm checking it in on Stuart's behalf.
The BCM4401 is built into several x86 laptop and desktop systems. For the
moment, I have only enabled it in the x86 kernel config because although
it's a PCI device, I haven't heard of any standalone NICs that use it. If
somebody knows of one, we can easily add it to the other arches.
This driver uses register/structure data gleaned from the Linux
driver released by Broadcom, but does not contain any of the code
from the Linux driver itself. It uses busdma.
device special files created by sio(4). The latter are the device
special files created by uart(4). As of this moment sio(4) is not
supported on ia64... by me, that is :-)
with the vendor sendmail distribution. By doing so, we avoid mergemaster
warnings after every 'make' in /etc/mail/.
Reported by: Jeremy Chadwick <koitsu@parodius.com>
MFC after: 3 days
X-MFC after: and re approval
o The following additional configuration attributes of a jail can be
controlled from rc.conf:
- mounting devfs(5)
- mounting fdescfs(5)
- mounting procfs(5)
- custom devfs(8) ruleset
If no ruleset is specified, the default jail ruleset is used.
o The output of executing /etc/rc in the jail is now redirected
to /dev/null. Instead, the hostname of the jail is echoed if
the jail(8) command exited successfully. If the output is wanted
it can probably be redirected to a file (/var/run/$jail maybe)
instead of /dev/null.
Submitted by: Scot W. Hetzel <hetzels@westbend.net>
with modifications by Jens Rehsack <rehsack@liwing.de>
and me.
the src/etc makefile. This list was used to manually
install the files from src/etc. Instead, simply change
directory and 'make install'.
o There is no reason for the files in src/etc/defaults to
be installed as writeable.
Reviewed by: ru
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.
use the atmconfig(8) utility instead of route(8) to install those routes.
For this we need a new rc.conf variable natm_static_routes that works
just like static_routes except that the referenced routes use the syntax
of atmconfig(8).
Okay'ed by: mtm
one internal device. Don't call the startup procedure again if
we already use start.
Support a manually started dhclient and keep its configured
interfaces after pccard removal.
Make pccard_ether working in single-user mode without /usr mounted.
There are now many configurations which have a NIC on board, and
pccard slots. If a dhclient is running on the internal nic, the
Improve the handling dhcp handling of pccard_ether.
Improve the dhcp handling of pccard_ether.
There are now many configurations which have a NIC on board and
Improve the dhcp handling of pccard_ether.
There are now many configurations which have a NIC on board and
cardbus slots too. If a dhclient was already running on the internal
NIC, the user was forced to kill a running dhclient manually.
If now a pccard is included at startup time, /etc/rc.d/dhclient
start does include it into the startup list for dhcp devices.
That means you can now do dhcp on the internal and the pccard devices
at the same time. If the card is plugged in later, a running dhclient
(working for the internal interface only) is killed, and restarted,
but the interface name of the new pccard is added to the internal
name. After removal, /etc/rc.d/dhclient is started again. This
script does nothing if there are no devices in /etc/rc.conf
This is only a workaround for a well known problem. After we have
a dhcp client which handles device adding and removal, it will go
away.
The original name was really a mistake since
/usr/local/etc/rc.d scripts can (and usually do) start
more than just daemons. Even the output in the script
uses 'local packages.' Also, the term 'local daemons' is
used by rc.d/local, which was etc/rc.local of rcOG fame.
No repo-copy because there isn't much history to save.
I will remove localdaemons shortly with all the other
files that don't belong in rc.d anymore.
Discussed with: dougb, freebsd-rc@yahoogroups.com
