freebsd-nq/etc/defaults/periodic.conf

396 lines
12 KiB
Plaintext
Raw Normal View History

#!/bin/sh
#
# This is defaults/periodic.conf - a file full of useful variables that
# you can set to change the default behaviour of periodic jobs on your
# system. You should not edit this file! Put any overrides into one of the
# $periodic_conf_files instead and you will be able to update these defaults
# later without spamming your local configuration information.
#
# The $periodic_conf_files files should only contain values which override
# values set in this file. This eases the upgrade path when defaults
# are changed and new features are added.
#
# For a more detailed explanation of all the periodic.conf variables, please
# refer to the periodic.conf(5) manual page.
#
# $FreeBSD$
#
# What files override these defaults ?
periodic_conf_files="/etc/periodic.conf /etc/periodic.conf.local"
# periodic script dirs
local_periodic="/usr/local/etc/periodic"
# Daily options
# These options are used by periodic(8) itself to determine what to do
# with the output of the sub-programs that are run, and where to send
# that output. $daily_output might be set to /var/log/daily.log if you
# wish to log the daily output and have the files rotated by newsyslog(8)
#
daily_output="root" # user or /file
daily_show_success="YES" # scripts returning 0
daily_show_info="YES" # scripts returning 1
daily_show_badconfig="NO" # scripts returning 2
# 100.clean-disks
daily_clean_disks_enable="NO" # Delete files daily
daily_clean_disks_files="[#,]* .#* a.out *.core *.CKP .emacs_[0-9]*"
daily_clean_disks_days=3 # If older than this
daily_clean_disks_verbose="YES" # Mention files deleted
# 110.clean-tmps
daily_clean_tmps_enable="NO" # Delete stuff daily
daily_clean_tmps_dirs="/tmp" # Delete under here
daily_clean_tmps_days="3" # If not accessed for
daily_clean_tmps_ignore=".X*-lock .X11-unix .ICE-unix .font-unix .XIM-unix"
daily_clean_tmps_ignore="$daily_clean_tmps_ignore quota.user quota.group .snap"
daily_clean_tmps_ignore="$daily_clean_tmps_ignore .sujournal"
# Don't delete these
daily_clean_tmps_verbose="YES" # Mention files deleted
# 120.clean-preserve
daily_clean_preserve_enable="YES" # Delete files daily
daily_clean_preserve_days=7 # If not modified for
daily_clean_preserve_verbose="YES" # Mention files deleted
# 130.clean-msgs
daily_clean_msgs_enable="YES" # Delete msgs daily
daily_clean_msgs_days= # If not modified for
# 140.clean-rwho
daily_clean_rwho_enable="YES" # Delete rwho daily
daily_clean_rwho_days=7 # If not modified for
daily_clean_rwho_verbose="YES" # Mention files deleted
# 150.clean-hoststat
daily_clean_hoststat_enable="YES" # Purge sendmail host
# status cache daily
# 200.backup-passwd
daily_backup_passwd_enable="YES" # Backup passwd & group
# 210.backup-aliases
daily_backup_aliases_enable="YES" # Backup mail aliases
# 300.calendar
daily_calendar_enable="NO" # Run calendar -a
# 310.accounting
daily_accounting_enable="YES" # Rotate acct files
daily_accounting_compress="NO" # Gzip rotated files
daily_accounting_flags=-q # Flags to /usr/sbin/sa
daily_accounting_save=3 # How many files to save
# 330.news
daily_news_expire_enable="YES" # Run news.expire
# 400.status-disks
daily_status_disks_enable="YES" # Check disk status
daily_status_disks_df_flags="-l -h" # df(1) flags for check
# 401.status-graid
daily_status_graid_enable="NO" # Check graid(8)
# 404.status-zfs
daily_status_zfs_enable="NO" # Check ZFS
daily_status_zfs_zpool_list_enable="YES" # List ZFS pools
# 406.status-gmirror
daily_status_gmirror_enable="NO" # Check gmirror(8)
# 407.status-graid3
daily_status_graid3_enable="NO" # Check graid3(8)
# 408.status-gstripe
daily_status_gstripe_enable="NO" # Check gstripe(8)
# 409.status-gconcat
daily_status_gconcat_enable="NO" # Check gconcat(8)
# 420.status-network
daily_status_network_enable="YES" # Check network status
daily_status_network_usedns="YES" # DNS lookups are ok
daily_status_network_netstat_flags="-d" # netstat(1) flags
# 430.status-uptime
daily_status_uptime_enable="YES" # Check system uptime
# 440.status-mailq
daily_status_mailq_enable="YES" # Check mail status
daily_status_mailq_shorten="NO" # Shorten output
daily_status_include_submit_mailq="YES" # Also submit queue
# 450.status-security
daily_status_security_enable="YES" # Security check
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
# See also "Security options" below for more options
daily_status_security_inline="NO" # Run inline ?
daily_status_security_output="root" # user or /file
# 460.status-mail-rejects
daily_status_mail_rejects_enable="YES" # Check mail rejects
daily_status_mail_rejects_logs=3 # How many logs to check
daily_status_mail_rejects_shorten="NO" # Shorten output
# 480.leapfile-ntpd
daily_ntpd_leapfile_enable="YES" # Fetch NTP leapfile
daily_ntpd_avoid_congestion="YES" # Avoid congesting
# leapfile sources
# 480.status-ntpd
daily_status_ntpd_enable="NO" # Check NTP status
# 500.queuerun
daily_queuerun_enable="YES" # Run mail queue
daily_submit_queuerun="YES" # Also submit queue
# 510.status-world-kernel
daily_status_world_kernel="YES" # Check the running
# userland/kernel version
# 800.scrub-zfs
daily_scrub_zfs_enable="NO"
daily_scrub_zfs_pools="" # empty string selects all pools
daily_scrub_zfs_default_threshold="35" # days between scrubs
#daily_scrub_zfs_${poolname}_threshold="35" # pool specific threshold
# 999.local
daily_local="/etc/daily.local" # Local scripts
# Weekly options
# These options are used by periodic(8) itself to determine what to do
# with the output of the sub-programs that are run, and where to send
# that output. $weekly_output might be set to /var/log/weekly.log if you
# wish to log the weekly output and have the files rotated by newsyslog(8)
#
weekly_output="root" # user or /file
weekly_show_success="YES" # scripts returning 0
weekly_show_info="YES" # scripts returning 1
weekly_show_badconfig="NO" # scripts returning 2
# 310.locate
weekly_locate_enable="YES" # Update locate weekly
# 320.whatis
weekly_whatis_enable="YES" # Update whatis weekly
# 330.catman
weekly_catman_enable="NO" # Preformat man pages
# 340.noid
weekly_noid_enable="NO" # Find unowned files
weekly_noid_dirs="/" # Look here
# 450.status-security
weekly_status_security_enable="YES" # Security check
# See also "Security options" above for more options
weekly_status_security_inline="NO" # Run inline ?
weekly_status_security_output="root" # user or /file
# 999.local
weekly_local="/etc/weekly.local" # Local scripts
# Monthly options
# These options are used by periodic(8) itself to determine what to do
# with the output of the sub-programs that are run, and where to send
# that output. $monthly_output might be set to /var/log/monthly.log if you
# wish to log the monthly output and have the files rotated by newsyslog(8)
#
monthly_output="root" # user or /file
monthly_show_success="YES" # scripts returning 0
monthly_show_info="YES" # scripts returning 1
monthly_show_badconfig="NO" # scripts returning 2
# 200.accounting
monthly_accounting_enable="YES" # Login accounting
# 450.status-security
monthly_status_security_enable="YES" # Security check
# See also "Security options" above for more options
monthly_status_security_inline="NO" # Run inline ?
monthly_status_security_output="root" # user or /file
# 999.local
monthly_local="/etc/monthly.local" # Local scripts
# Security options
security_show_success="YES" # scripts returning 0
security_show_info="YES" # scripts returning 1
security_show_badconfig="NO" # scripts returning 2
2002-08-09 20:58:54 +00:00
# These options are used by the security periodic(8) scripts spawned in
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
# daily and weekly 450.status-security.
security_status_logdir="/var/log" # Directory for logs
security_status_diff_flags="-b -u" # flags for diff output
# Each of the security_status_*_period options below can have one of the
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
# following values:
# - NO: do not run at all
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
# - daily: only run during the daily security status
# - weekly: only run during the weekly security status
# - monthly: only run during the monthly security status
# Note that if periodic security scripts are run from crontab(5) directly,
# they will be run unless _enable or _period is set to "NO".
# 100.chksetuid
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_chksetuid_enable="YES"
security_status_chksetuid_period="daily"
# 110.neggrpperm
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_neggrpperm_enable="YES"
security_status_neggrpperm_period="daily"
# 200.chkmounts
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_chkmounts_enable="YES"
security_status_chkmounts_period="daily"
#security_status_chkmounts_ignore="^amd:" # Don't check matching
# FS types
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_noamd="NO" # Don't check amd mounts
# 300.chkuid0
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_chkuid0_enable="YES"
security_status_chkuid0_period="daily"
# 400.passwdless
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_passwdless_enable="YES"
security_status_passwdless_period="daily"
# 410.logincheck
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_logincheck_enable="YES"
security_status_logincheck_period="daily"
# 500.ipfwdenied
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_ipfwdenied_enable="YES"
security_status_ipfwdenied_period="daily"
# 510.ipfdenied
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_ipfdenied_enable="YES"
security_status_ipfdenied_period="daily"
# 520.pfdenied
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_pfdenied_enable="YES"
security_status_pfdenied_period="daily"
# 550.ipfwlimit
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_ipfwlimit_enable="YES"
security_status_ipfwlimit_period="daily"
# 610.ipf6denied
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_ipf6denied_enable="YES"
security_status_ipf6denied_period="daily"
# 700.kernelmsg
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_kernelmsg_enable="YES"
security_status_kernelmsg_period="daily"
# 800.loginfail
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_loginfail_enable="YES"
security_status_loginfail_period="daily"
# 900.tcpwrap
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
security_status_tcpwrap_enable="YES"
security_status_tcpwrap_period="daily"
# Define source_periodic_confs, the mechanism used by /etc/periodic/*/*
# scripts to source defaults/periodic.conf overrides safely.
if [ -z "${source_periodic_confs_defined}" ]; then
source_periodic_confs_defined=yes
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
# Compatibility with old daily variable names.
# They can be removed in stable/11.
security_daily_compat_var() {
local var=$1 dailyvar value
dailyvar=daily_status_security${var#security_status}
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
periodvar=${var%enable}period
eval value=\"\$$dailyvar\"
[ -z "$value" ] && return
echo "Warning: Variable \$$dailyvar is deprecated," \
"use \$$var instead." >&2
case "$value" in
[Yy][Ee][Ss])
eval $var=YES
eval $periodvar=daily
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
;;
*)
2013-10-29 20:38:19 +00:00
eval $var=\"$value\"
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
;;
esac
}
check_yesno_period() {
local var="$1" periodvar value period
eval value=\"\$$var\"
case "$value" in
[Yy][Ee][Ss]) ;;
*) return 1 ;;
esac
periodvar=${var%enable}period
eval period=\"\$$periodvar\"
case "$PERIODIC" in
"security daily")
case "$period" in
[Dd][Aa][Ii][Ll][Yy]) return 0 ;;
*) return 1 ;;
esac
;;
"security weekly")
case "$period" in
[Ww][Ee][Ee][Kk][Ll][Yy]) return 0 ;;
*) return 1 ;;
esac
;;
"security monthly")
case "$period" in
[Mm][Oo][Nn][Tt][Hh][Ll][Yy]) return 0 ;;
*) return 1 ;;
esac
;;
security)
# Run directly from crontab(5).
case "$period" in
[Nn][Oo]) return 1 ;;
*) return 0 ;;
esac
;;
'')
# Script run manually.
return 0
;;
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
*)
echo "ASSERTION FAILED: Unexpected value for" \
Make the period of each periodic security script configurable. There are now six additional variables weekly_status_security_enable weekly_status_security_inline weekly_status_security_output monthly_status_security_enable monthly_status_security_inline monthly_status_security_output alongside their existing daily counterparts. They all have the same default values. All other "daily_status_security_${scriptname}_${whatever}" variables have been renamed to "security_status_${name}_${whatever}". A compatibility shim has been introduced for the old variable names, which we will be able to remove in 11.0-RELEASE. "security_status_${name}_enable" is still a boolean but a new "security_status_${name}_period" allows to define the period of each script. The value is one of "daily" (the default for backward compatibility), "weekly", "monthly" and "NO". Note that when the security periodic scripts are run directly from crontab(5) (as opposed to being called by daily or weekly periodic scripts), they will run unless the test is explicitely disabled with a "NO", either for in the "_enable" or the "_period" variable. When the security output is not inlined, the mail subject has been changed from "$host $arg run output" to "$host $arg $period run output". For instance: myfbsd security run output -> myfbsd security daily run output I don't think this is considered as a stable API, but feel free to correct me if I'm wrong. Finally, I will rearrange periodic.conf(5) and default/periodic.conf to put the security options in their own section. I left them in place for this commit to make reviewing easier. Reviewed by: hackers@
2013-08-27 21:20:28 +00:00
"\$PERIODIC: '$PERIODIC'" >&2
exit 127
;;
esac
}
2012-07-13 06:46:09 +00:00
source_periodic_confs() {
local i sourced_files
for i in ${periodic_conf_files}; do
case ${sourced_files} in
*:$i:*)
;;
*)
sourced_files="${sourced_files}:$i:"
[ -r $i ] && . $i
;;
esac
done
}
fi