rc.d: add a service jails config to all base system services

This gives more permissions to services (e.g. network access to
services which require this) when they are started as an automatic
servic

rc.d: add a service jails config to all base system services

This gives more permissions to services (e.g. network access to
services which require this) when they are started as an automatic
service jail.

The sshd patch is important for the sshd-related functionality as
described in the man-page in the service jails part.

The location of the added env vars is supposed to allow overriding them
in rc.conf, and to hard-disable the use of svcj for some parts where it
doesn't make sense or will not work.

Only a subset of all of the services are fully tested (I'm running this
since more than a year with various services started as service jails).
The untested parts should be most of the time ok, in some edge-cases
more permissions are needed inside the service jail.
Differential Revision: https://reviews.freebsd.org/D40371

show more ...

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

dumpdev: respect kenv for stable branches

We have somewhat twisted logic to determine actions for dumpdev
considering three sources of information:

* kenv "dumpdev" tunnable supposed to point to sp

dumpdev: respect kenv for stable branches

We have somewhat twisted logic to determine actions for dumpdev
considering three sources of information:

* kenv "dumpdev" tunnable supposed to point to specific device;
* /etc/defaults/rc.conf "dumpdev" variable;
* /etc/rc.conf that may be unset or set to "NO", "AUTO" or device name.

For CURRENT without any setting in kenv or /etc/rc.conf
the default is "AUTO". For STABLE branches the default is "NO".

Current implementation breaks for STABLE branches if kenv points
to specific device but /etc/rc.conf does not set "dumpdev" at all.

Let us fix it commenting out "dumpdev" in /etc/defaults/rc.conf
for STABLE branches and making the code to consult kenv
if "dumpdev" is not set elsewhere.

MFC-after: 1 month

show more ...

dumpon: use underlying device if encrypted swap is in use

/etc/rc.d/dumpon runs before /etc/rc.d/swap. When encrypted swap is in
use the .eli or .bde device will not exist at the time dumpon runs.

dumpon: use underlying device if encrypted swap is in use

/etc/rc.d/dumpon runs before /etc/rc.d/swap. When encrypted swap is in
use the .eli or .bde device will not exist at the time dumpon runs.

Even if this is addressed it does not make sense to dump core to
encrypted swap, as the encryption key will not be available after
reboot rendering the dump useless. Thus, for the case that dumpdev=AUTO
and encrypted swap is in use, strip the extension and use the underlying
device.

Emit a warning if we are using the underlying device and the user has not
configured dump encryption, so that the user knows that the will not be
encrypted.

PR: 238301
Reported by: Ivan Rozhuk
Reviewed by: jilles
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34474

show more ...

wait for device mounts in zpool and dumpon

If the root file system is composed from multiple devices, wait for
devices to be ready before running zpool and dumpon rc scripts.

An example of this is

wait for device mounts in zpool and dumpon

If the root file system is composed from multiple devices, wait for
devices to be ready before running zpool and dumpon rc scripts.

An example of this is if the bulk of the root file system exists on a
fast device (e.g. NVMe) but the /var directory comes from a ZFS dataset
on a slower device (e.g. SATA). In this case, it is possible that the
zpool import may run before the slower device has finished being probed,
leaving the system in an intermediate state.

Fix is to add root_hold_wait to the zpool and dumpon (which has a
similar issue) rc scripts.

PR: 242189
Reported by: osidorkin@gmail.com
Reviewed by: allanjude
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D29101

show more ...

Merge ^/head r339015 through r339669.

Move the rc framework out of sbin/init into libexec/rc.

The reasons for this are forward looking to pkgbase:
* /sbin/init is a special binary; try not to replace it with
every package update bec

Move the rc framework out of sbin/init into libexec/rc.

The reasons for this are forward looking to pkgbase:
* /sbin/init is a special binary; try not to replace it with
every package update because an rc script was touched.
(a follow-up commit will make init its own package)
* having rc in its own place will allow more easy replacement
of the rc framework with alternatives, such as openrc.

Discussed with: brd (during BSDCam), kmoore
Requested by: cem, bz
PR: 231522
Approved by: re (gjb)

show more ...