I incorrectly started this pattern in r277541 with the opensm newsyslog.conf.d file,
and continued using it in r318441 and r318443.
This will fix the files being handled improperly via installworld, preventing tools like
etcupdate, mergemaster, etc from functioning properly when comparing the installed
contents on a system vs the contents in a source tree when doing merges.
PR: 219404
Submitted by: Dan McGregor <dan.mcgregor@usask.ca>
MFC after: 2 weeks
MFC with: r277541, r318441, r318443
Sponsored by: Dell EMC Isilon
The default crontab prior to this commit assumes atrun(8) is always
present, which isn't true if MK_AT == no. Move atrun(8) execution
from /etc/crontab to /etc/cron.d/at, and base /etc/cron.d/at's installation
on MK_AT. cron(8) will detect /etc/cron.d/at's presence when the configuration
is loaded and run atrun every 5 minutes like it would prior to this commit.
SHELL and PATH are duplicated between /etc/crontab and /etc/cron.d/at
because atrun(8) executes programs, which may rely on environment
set in the current default /etc/crontab.
Noted by: bdrewery (in an internal review)
MFC after: 2 months
Relnotes: yes (may need to add environmental modifications to
/etc/cron.d/at)
Sponsored by: Dell EMC Isilon
Install /etc/cron.d/at if MK_AT != no, always using it, which tries
to run a non-existent program via cron(8) every 5 minutes with the
default /etc/crontab, prior to this commit.
SHELL and PATH are duplicated between /etc/crontab and /etc/cron.d/at
because atrun(8) executes programs, which may rely on environment
currently set via /etc/crontab.
Noted by: bdrewery (in an internal review)
MFC after: 2 months
Relnotes: yes (may need to add environmental modifications to
/etc/cron.d/at)
Sponsored by: Dell EMC Isilon
Items tested via this commit are:
- Some basic POSIX constants.
- Some valid programming environments with -v.
- Some invalid programming environments via -v.
NOTE: this test makes assumptions about ILP32/LP32 vs LP64 that are
currently not true on all architectures to avoid hardcoding some
architectures in the tests. I'm working on improving getconf(1) to be
more sane about handling ILP32/LP32 vs LP64. Future commits are coming
soon to address this.
MFC after: 2 weeks
Tested with: amd64, i386
Sponsored by: Dell EMC Isilon
These tests query a running process for information related to the -b,
-c, -e, and -f flags; the -f testcase is largely stubbed out, pending
additional work to determine a good, deterministic descriptor.
Core file test support is coming soon--it requires a bit more effort
due to the fact that:
- coredumps can be disabled (kern.coredump=0).
- corefiles can be put in different directories than the current
directory, or be named something other than `<prog>.core`
(`kern.corefile`).
MFC after: 2 months
Sponsored by: Dell EMC Isilon
src.conf(5) knobs
This will allow consumers of FreeBSD to use the unmodified configuration
files out of the box more than previously.
Both newsyslog.conf and syslog.conf:
- /var/log/lpd-errs (MK_LPR != no)
- /var/log/ppp.log (MK_PPP != no)
- /var/log/xferlog (MK_FTP != no)
newsyslog.conf:
- /var/log/amd.log (MK_AMD != no)
- /var/log/pflog (MK_PF != no)
- /var/log/sendmail.st (MK_SENDMAIL != no)
MFC after: 3 weeks
Sponsored by: Dell EMC Isilon
With fstyp(8) being updated to detect exfat in base r312003, it seems
like a good time to add support for auto-mounting SDXC cards -- which
use exfat by default.
The user will need to locally compile and install sysutils/fusefs-exfat
for this to succeed; logs a message to that effect when not installed.
PR: 218743
Submitted by: eborisch+FreeBSD@gmail.com
MFC after: 2 weeks
This makes 'stop' behave consistently with 'start' in the script.
Also use $SYSCTL instead of sysctl for consistency within that script.
MFC after: 3 weeks
patm(4) devices.
Maintaining an address family and framework has real costs when we make
infrastructure improvements. In the case of NATM we support no devices
manufactured in the last 20 years and some will not even work in modern
motherboards (some newer devices that patm(4) could be updated to
support apparently exist, but we do not currently have support).
With this change, support remains for some netgraph modules that don't
require NATM support code. It is unclear if all these should remain,
though ng_atmllc certainly stands alone.
Note well: FreeBSD 11 supports NATM and will continue to do so until at
least September 30, 2021. Improvements to the code in FreeBSD 11 are
certainly welcome.
Reviewed by: philip
Approved by: harti
/etc/pam.d/ftp* should be installed with MK_FTP != no and
/etc/pam.d/telnetd should be installed when MK_TELNET != no.
MFC after: 7 weeks
Sponsored by: Dell EMC Isilon
etc/rc.d/dhclient unconditionally testing true when called by a devd
rule during boot, ignoring statically assigned IP addresses in rc.conf.
Requested by: des@
Areas not covered still [positive functionality wise] are:
- sbuf_{clear,get,set}_flags
- sbuf_new (in particular, with fixed buffers, etc).
Some basic negative testing has been added, but more will be added in the
future.
This work was in part to validate work done by cem in r288223, and ian
before that.
MFC after: 2 months
Sponsored by: Dell EMC Isilon
Previously, 450.status-security would always set rc=3 in inline mode,
because it doesn't know whether "periodic security" is going to find
anything interesting. But this annoyingly results in daily reports that
simply say "Security check: \n\n-- End of daily output --".
This change fixes that by testing whether "periodic security" printed
anything, and setting 450.status-security's exit status to 3 if it did. An
alternative would be to change the exit status of periodic(8) to be the
worst of its scripts' exit statuses, but that would be a more intrusive
change.
Reviewed by: brian
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D10267
and NULL (for no) to "no" (for no) and no change to the definition
of yes. Two rc.d scripts, dhclient and bgfsck check rc_force for
yesi, using test -n, and no, using test -z. The redefinition of
yes and no by r316487 caused rc.d/dhclient, when invoked by devd
using a devd.conf rule, to assign DHCP assigned IP addresses for
interfaces with statically assigned interfaces, breaking boot.
Point of breakage was at line 25 of etc/rc.d/dhclient (r301068)
where $rc_force needs to be NULL.
MFC after: 3 weeks
X-MFC with: r316487
Multiple periodic scripts sleep for a random amount of time in order to
mitigate the thundering herd problem. This is bad, because the sum of
multiple uniformly distributed random variables approaches a normal
distribution, so the problem isn't mitigated as effectively as it would be
with a single sleep.
This change creates a single configurable anticongestion sleep. periodic
will only sleep if at least one script requires it, and it will never sleep
more than once per invocation. It also won't sleep if periodic was run
interactively, fixing an unrelated longstanding bug.
PR: 217055
PR: 210188
Reviewed by: cy
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D10211
- kvm_close: add a testcase to verify support for errno = EINVAL / -1
(see D10065) when kd == NULL is provided to the libcall.
- kvm_geterr:
-- Add a negative testcase for kd == NULL returning "" (see D10022).
-- Add two positive testcases:
--- test the error case using kvm_write on a O_RDONLY descriptor.
--- test the "no error" case using kvm_read(3) and kvm_nlist(3) as
helper routines and by injecting a bogus error message via
_kvm_err (an internal API) _kvm_err was used as there isn't a
formalized way to clear the error output, and because
kvm_nlist always returns ENOENT with the NULL terminator today.
- kvm_open, kvm_open2:
-- Add some basic negative tests for kvm_open(3) and kvm_open2(3).
Testing positive cases with a specific
`corefile`/`execfile`/`resolver` requires more work and would require
user intervention today in order to reliably test this out.
Reviewed by: markj
MFC after: 2 months
Sponsored by: Dell EMC Isilon
Differential Revision: D10024
This, like including ucl private headers, is useful for writing new base
system tools. Yes, anyone using these libraries shouldn't assume ABI
compatibility.
Reviewed by: bdrewery, bapt
Differential Revision: https://reviews.freebsd.org/D10123
the default partition, eMMC v4.41 and later devices can additionally
provide up to:
1 enhanced user data area partition
2 boot partitions
1 RPMB (Replay Protected Memory Block) partition
4 general purpose partitions (optionally with a enhanced or extended
attribute)
Of these "partitions", only the enhanced user data area one actually
slices the user data area partition and, thus, gets handled with the
help of geom_flashmap(4). The other types of partitions have address
space independent from the default partition and need to be switched
to via CMD6 (SWITCH), i. e. constitute a set of additional "disks".
The second kind of these "partitions" doesn't fit that well into the
design of mmc(4) and mmcsd(4). I've decided to let mmcsd(4) hook all
of these "partitions" up as disk(9)'s (except for the RPMB partition
as it didn't seem to make much sense to be able to put a file-system
there and may require authentication; therefore, RPMB partitions are
solely accessible via the newly added IOCTL interface currently; see
also below). This approach for one resulted in cleaner code. Second,
it retains the notion of mmcsd(4) children corresponding to a single
physical device each. With the addition of some layering violations,
it also would have been possible for mmc(4) to add separate mmcsd(4)
instances with one disk each for all of these "partitions", however.
Still, both mmc(4) and mmcsd(4) share some common code now e. g. for
issuing CMD6, which has been factored out into mmc_subr.c.
Besides simply subdividing eMMC devices, some Intel NUCs having UEFI
code in the boot partitions etc., another use case for the partition
support is the activation of pseudo-SLC mode, which manufacturers of
eMMC chips typically associate with the enhanced user data area and/
or the enhanced attribute of general purpose partitions.
CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation.
- Now that properly issuing CMD6 is crucial (so data isn't written to
the wrong partition for example), make a step into the direction of
correctly handling the timeout for these commands in the MMC layer.
Also, do a SEND_STATUS when CMD6 is invoked with an R1B response as
recommended by relevant specifications. However, quite some work is
left to be done in this regard; all other R1B-type commands done by
the MMC layer also should be followed by a SEND_STATUS (CMD13), the
erase timeout calculations/handling as documented in specifications
are entirely ignored so far, the MMC layer doesn't provide timeouts
applicable up to the bridge drivers and at least sdhci(4) currently
is hardcoding 1 s as timeout for all command types unconditionally.
Let alone already available return codes often not being checked in
the MMC layer ...
- Add an IOCTL interface to mmcsd(4); this is sufficiently compatible
with Linux so that the GNU mmc-utils can be ported to and used with
FreeBSD (note that due to the remaining deficiencies outlined above
SANITIZE operations issued by/with `mmc` currently most likely will
fail). These latter will be added to ports as sysutils/mmc-utils in
a bit. Among others, the `mmc` tool of the GNU mmc-utils allows for
partitioning eMMC devices (tested working).
- For devices following the eMMC specification v4.41 or later, year 0
is 2013 rather than 1997; so correct this for assembling the device
ID string properly.
- Let mmcsd.ko depend on mmc.ko. Additionally, bump MMC_VERSION as at
least for some of the above a matching pair is required.
- In the ACPI front-end of sdhci(4) describe the Intel eMMC and SDXC
controllers as such in order to match the PCI one.
Additionally, in the entry for the 80860F14 SDXC controller remove
the eMMC-only SDHCI_QUIRK_INTEL_POWER_UP_RESET.
OKed by: imp
Submitted by: ian (mmc_switch_status() implementation)
This change contains several negative and positive tests for:
- cam_open_device
- cam_close_device
- cam_getccb
- cam_freeccb
This also contains a test for the failure case noted in bug 217649,
i.e., O_RDWR must be specified because pass(4) requires it.
This test unfortunately cannot assume that cam-capable devices are
present, so the user must explicitly provide a device via
`test_suites.FreeBSD.cam_test_device`. In the future, a test kernel
module might be shipped, or ctl(4) might be used, as a test device
when testing out libcam, which will allow the tests to do away with
having to specify an explicit test device.
Reviewed by: asomers, ken (earlier diff)
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: D9928
This change moves the tests added in r313962 to an existing directory
structure used by the geli TAP tests. It also, renames the test from
pbkdf2 to pbkdf2_test .
The changes to ObsoleteFiles.inc are being committed separately as they
aren't needed for the MFC to ^/stable/11, etc, if the MFC for the tests
is done all in one commit.
MFC after: 2 weeks
X-MFC with: r313962, r313972-r313973
Reviewed by: allanjude
Sponsored by: Dell EMC Isilon
Differential Revision: D9985
Prefer ${SRCTOP}/ to ${.CURDIR}/../ and ${.CURDIR}/../../ as appropriate.
Differential Revision: https://reviews.freebsd.org/D9932
Sponsored by: Netflix
Silence On: arch@ (twice)
It relies on output from inetd that is triggered by MK_TCP_WRAPPERS=yes.
We need to check for both knobs being set -- otherwise the script doesn't
have much value.
PR: 217577
Submitted by: Sergey <kpect@protonmail.com> (MK_TCP_WRAPPERS piece)
MFC after: 1 week
Sponsored by: Dell EMC Isilon
