Weekly Unbound Updates on RaspberryPi

Uncategorized

Weekly Unbound Updates on RaspberryPi

Information and configuration steps around setting up an automated cron job to pool the root hints weekly and restart unbound after doing so.

Helpful links

Crontab site(s)

Unbound Installation / Scheduling Info

The goal is to create a weekly schedule to run a script which will:

  1. Download a fresh set of root hints for unbound to use once a week
  2. Restart the unbound service to accept the new root hints

Cron Schedule String

The portion of the crontab line that dictates the scheduling.

"At 03:15 every Sunday."

15 3 * * 0

File locations

The locations I am using to store the scritpts this will use.

  • /usr/local/bin/
    • update-unbound-root-hints.sh
      • Updates the root hints
    • unbound-weekly-maintenance.sh
      • Calls the update-unbound-root-hints.sh and then restarts unbound

Script Source

The source for the two scripts listed above.

  1. update-unbound-root-hints.sh

    #!/bin/bash
    
    wget -O root.hints https://www.internic.net/domain/named.root
    mv root.hints /var/lib/unbound/
    
  2. unbound-weekly-maintenance.sh

    #!/bin/bash
    
    #Update root hints
    sh /usr/local/bin/update-unbound-root-hints.sh
    
    #Restart Unbound
    systemctl restart unbound
    

Example Crontab line

# backup using the rsbu program to the internal 4TB HDD and then 4TB external
01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2

As a user Crontab line

Some jobs are more appropriate to run under a user context rather than root. The following Crontab line would be added in the users crontab file by running crontab -e as the user.

15 3 * * 0 sh /usr/local/bin/unbound-weekly-maintenance.sh > /usr/local/bin/unbound-weekly-maintenance.log 2>&1

The /etc/crontab line

System-wide jobs seem more appropriate to run vi the /etc/crontab file specifying the user in question.

15 3    * * 0   root    sh /usr/local/bin/unbound-weekly-maintenance.sh > /usr/local/bin/unbound-weekly-maintenance.log 2>&1

Pi-hole specific cron jobs

My pi-hole has this cron configuration in: /etc/cron.d/pihole.conf

# This file is under source-control of the Pi-hole installation and update
# scripts, any changes made to this file will be overwritten when the software
# is updated or re-installed. Please make any changes to the appropriate crontab
# or other cron file snippets.

# Pi-hole: Update the ad sources once a week on Sunday at a random time in the
#          early morning. Download any updates from the adlists
#          Squash output to log, then splat the log to stdout on error to allow for
#          standard crontab job error handling.
16 4   * * 7   root    PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updateGravity >/var/log/pihole_updateGravity.log || cat /var/log/pihole_updateGravity.log

# Pi-hole: Flush the log daily at 00:00
#          The flush script will use logrotate if available
#          parameter "once": logrotate only once (default is twice)
#          parameter "quiet": don't print messages
00 00   * * *   root    PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole flush once quiet

@reboot root /usr/sbin/logrotate /etc/pihole/logrotate

# Pi-hole: Grab local version and branch every 10 minutes
*/10 *  * * *   root    PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updatechecker local

# Pi-hole: Grab remote version every 24 hours
38 14  * * *   root    PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updatechecker remote
@reboot root    PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updatechecker remote reboot

crontab -e as user: pi yields the following configuration. Note the #0 2 1 */4 * /usr/local/bin/update-unbound-root-hints.sh > unbound-root-hint-update.log is commented out. There is nothing wrong with this but there is nothing in this to do.

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
#0 2 1 */4 *  /usr/local/bin/update-unbound-root-hints.sh > unbound-root-hint-update.log

Whereas, running sudo crontab -e yields. Note that 0 2 1 */4 * /usr/local/bin/update-unbound-root-hints.sh > unbound-root-hint-update.log is not commented out here as the root user.

The schedule below is

At 01:02 on every 4th day-of-month.

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
0 2 1 */4 *  /usr/local/bin/update-unbound-root-hints.sh > unbound-root-hint-update.log