Apparently using tty for this purpose has been deprecated since 4.4 Lite.
Reviewed by: cy
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D21318
Revision 316342, which introduced the anticongestion feature, failed to
consider that the periodic scripts are executed by a recursive invocation of
periodic. The recursive invocation wrongly cleaned up a temporary file that
should've been cleaned up only by the original invocation. The result is
that if the first script that requests an anticongestion sleep runs after
the security scripts, the sleep won't happen.
Fix this bug by delaying cleanup until the end of the original invocation.
PR: 236564
Submitted by: Yasuhiro KIMURA <yasu@utahime.org>
Reviewed by: imp
MFC after: 1 month
In 2011, r218961 removed local code for rotating logs in favor of using the
rotate_log command in etc/rc.d/accounting. If the accounting service is
activated then subsequently de-activated in rc.conf but still remains active
in periodic.conf, then you get an error message every day in the periodic
jobs about being unable to rotate the logs.
With this change to use "onerotate_log", the log rotation will happen the
first time periodic daily runs after accounting was disabled but periodic
accounting was left enabled. After that happens once, the /var/account/acct
will no longer exist, which results in a different path through the periodic
code and no more error messages will appear (unless daily_show_badconfig is
set, in which case the admin will be told that periodic security processing
is enabled but the accounting file is not present).
This is only a partial fix for the problems reported in PR 202203.
PR: 202203
on bsdinstall(8) and may be non-functional
for system built WITHOUT_BSDINSTALL. (*)
Also, add a check for jails sharing whole tree with host (path=/)
and do not skip it.
Reported by: Andre.Albsmeier@siemens.com (*)
MFC after: 1 week
Exit with a zero status when Postfix reports "Mail queue is empty" so this
section won't appear in the report at all when daily_show_success="NO".
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
of jails. Jails have their own user/group databases and this script
can produce multiple false warnings, not to mention significant extra
load in case of large jailed subtrees. Leave this check for jailed
invocations of the same script.
MFC after: 1 month
Ths prevents etcupdate and mergemaster from deleting it for now.
Approved by: re (rgrimes), will (mentor)
Differential Revision: https://reviews.freebsd.org/D16975
This makes pkgbase easier by tagging these as CONFS so they are properly
tagged as config files.
Approved by: will (mentor)
Sponsored by: Essen Hackathon
Differential Revision: https://reviews.freebsd.org/D16553
When called with an absolute pathname, periodic should attempt to execute
every script in that directory. If the directory does not exist, it should
print an error and exit 1. Due to a copy/paste mistake in r231568, it exits
0 in that case.
Reported by: devel/hs-ShellCheck
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13070
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
periodic(8) already handles the security_show_{success,info,badconfig}
variables correctly. However, those variables aren't explicitly set in
/etc/defaults/periodic.conf or anywhere else, which suggests to the user
that they shouldn't be used.
etc/defaults/periodic.conf
Explicitly set defaults for security_show_{success,info,badconfig}
usr.sbin/periodic/periodic.sh
Update usage string
usr.sbin/periodic/periodic.8
Minor man page updates
One thing I'm _not_ doing is recommending setting security_output to
/var/log/security.log or adding that file to /etc/newsyslog.conf, because
periodic(8) would create it with default permissions, usually 644, and
that's probably a bad idea.
Reviewed by: brd
MFC after: 4 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D6477
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
More concretely, periodic security scripts defaults to being
called from daily ones -- daily context -- so the mail subject
will now be "${HOST} daily security run output" instead of
"{HOST} security run output".
If you switch the period of some security checks to weekly, you
will receive another email "${HOST} weekly security run output".
starting up before the previous script finishes. This prevents an
infinite number of them from piling up and slowing a system down.
Since all the refactoring to make this happen required churning the
indenting of most of this file, make the indentation more consistent.
Reviewed by: simon
MFC after: 1 week
Although groff_mdoc(7) gives another impression, this is the ordering
most widely used and also required by mdocml/mandoc.
Reviewed by: ru
Approved by: philip, ed (mentors)
The man page part of the patch is my fault, the changes to the
periodic script is Dominik's.
PR: 88486
Submitted by: Dominik Brettnacher <domi@saargate.de>
Reviewed by: brian
Approved by: re
MFC after: 1 month
of /etc/daily. Some time later, /etc/daily became a set of periodic(8)
scripts. Now, this evolution continues, and /etc/security has been
broken into periodic(8) scripts to make local customization easier and
more maintainable.
Reviewed by: ru
Approved by: ru
it again and again, practically begging the Bad Man to insert his symlink
underneath it and send us down the path to oblivion.
Noticed by: David Lary <dlary@secureworks.net>
