| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
| |
- Remove extranious echo that breaks puppet
- Handle restarts of multiple pflog devices correctly
- Add the ability to perform actions on specific pflog devices.
PR: 199150
Submitted by: jason.unovitch@gmail.com
MFC after: 3 days
|
| |
|
|
|
|
|
|
|
| |
and pflog devices.
PR: conf/158171
Submitted by: Thomas Johnson <tom@claimlynx.com>
|
|
|
|
|
|
|
|
|
|
|
| |
systems are fully "ready to go".
'FILESYSTEMS' states: "This is a dummy dependency, for services which
require file systems to be mounted before starting." However, we have
'var' which is was run after 'FILESYSTEMS' and can mount /var if it
already isn't mounted. Furthermore, several scripts cannot use /var
until 'cleanvar' has done its thing. Thus "FILESYSTEMS" hasn't really
meant all critical file systems are fully usable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assignments to the literal values it would have returned.
The concept of set_rcvar() was nice in theory, but the forks
it creates are a drag on the startup process, which is especially
noticeable on slower systems, such as embedded ones.
During the discussion on freebsd-rc@ a preference was expressed for
using ${name}_enable instead of the literal values. However the
code portability concept doesn't really apply since there are so
many other places where the literal name has to be searched for
and replaced. Also, using the literal value is also a tiny bit
faster than dereferencing the variables, and every little bit helps.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allow them to start after netif. There were too many problems reported
with this change in the short period of time that it lived in HEAD, and
we are too late in the release cycle to properly shake it out.
IMO the issue of having the firewalls up before the network is still a
valid concern, particularly for pf whose default state is wide open.
However properly solving this issue is going to take some investment
on the part of the people who actually use those tools.
This is not a strict reversion of all the changes for r193198 since it
also included some simplification of the BEFORE/REQUIRE logic which is
still valid for ipfilter and ip6fw.
|
|
|
|
|
| |
already does. This eliminates a logical inconsistency, and a small
window where the system is open after the network comes up.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
and takes over mountcritlocal's role as the early / late divider. This
makes it far easier to add rc scripts which need to run early, such as a
startup script for zfs, which is right around the corner.
This change should be a no-op; I have verified that the only change in
rcorder's output is the insertion of FILESYSTEMS immediately after
mountcritlocal.
MFC after: 3 weeks
|
|
|
|
| |
cases. So we get rid of quite a few lines of duplicated code.
|
| |
|
|
|
|
|
|
| |
Submitted by: Antoine Brodin
PR: kern/88271
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
- utilize default methods instead of rolling local ones;
- avoid to specify BEFORE conditions we don't really need
(pflog will be REQUIRE'd by pf);
- omit extra decoration from warning messages, warn() will
decorate them sufficiently.
|
|
|
|
| |
No objections from: mlaier
|
| |
|
|
|
|
|
|
|
| |
makes any sense.
Discussed with: dougb, brooks
MFC after: 3 days
|
|
|
|
|
|
| |
dependency to it from our rc.d scripts.
Approved by: mtm
|
|
|
|
|
|
|
|
|
| |
part of the pf module.
While here fix a comment that was c'n'ped from rc.d/pf
PR: bin/71096 (partly)
Submitted by: Ville-Pertti Keinonen
MFC after: 2 days
|
|
rc.conf(5) and put a sample entry to newsyslog.conf
Reviewed by: -current
Approved by: bms(mentor)
|