• FreeBSD_Update

FreeBSD Update (freebsd-update)

FreeBSD Update is a binary update system for FreeBSD base. It consists of a server and client component.

• FreeBSD Handbook: FreeBSD Update

• freebsd-update(8) Manual Page

How to check for latest available version

$ fetch http://update.freebsd.org/12.0-RELEASE/amd64/pub.ssl     # Get public key. Verify the signature yourself [*]
$ fetch http://update.freebsd.org/12.0-RELEASE/amd64/latest.ssl  # Get metadata

$ openssl rsautl -pubin -inkey pub.ssl -verify <latest.ssl

Output looks like:

freebsd-update|amd64|12.0-RELEASE|10|cae42a89f90be555b530a759cd400925bce03ed73ee78e665bef3fe5293e872f|1576022400

"10" in the output of this example refers to p10, the 10th patch level for 12.0-RELEASE amd64

Verify freebsd-update server signature

The following compares the servers pub.ssl with the hash value that exists on the system:

$ sha256 -q pub.ssl
$ grep KeyPrint /etc/freebsd-update.conf | cut -f 2 -w

The outputs of the commands should be identical, indicating the signature is "good" (verified)

freebsd-update Reverse Proxy Cache

Either because you're a good netizen and don't want to repeatedly hammer the FreeBSD mirrors to upgrade all your systems, or you want to benefit from the speed of having a local "mirror" (cache, more precisely), running a freebsd update reverse proxy cache with, say, nginx is dead simple.

1. Install nginx somewhere

2. Configure nginx for a subdomain, say, freebsd-update.example.com

    proxy_cache_path /usr/local/www/cache/update keys_zone=freebsd_update:10m levels=1:2 max_size=1024M inactive=24h;

    server {
        listen          80;
        server_name     freebsd-update.example.com;
        root            /var/cache/freebsd-update/;

        location / {
            proxy_pass              http://update.freebsd.org;
            #proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_http_version      1.1;

            proxy_cache             freebsd_update;
            proxy_cache_lock        on;
            proxy_cache_lock_timeout    20s;
            proxy_cache_revalidate  on;

            # 24h is example TTL here, and can be really any period which you require to update all your systems
            # 
            proxy_cache_valid       200 301 302 404 24h;
        }
    }

3. On all your hosts, in all your jails, configure /etc/freebsd-update.conf for new ServerName

# $FreeBSD: stable/11/etc/freebsd-update.conf 257694 2013-11-05 09:30:06Z glebius $

# Trusted keyprint.  Changing this is a Bad Idea unless you've received
# a PGP-signed email from <security-officer@FreeBSD.org> telling you to
# change it and explaining why.
KeyPrint ...

# Server or server pool from which to fetch updates.  You can change
# this to point at a specific server if you want, but in most cases
# using a "nearby" server won't provide a measurable improvement in
# performance.
#ServerName update.FreeBSD.org
ServerName freebsd-update.example.com

.
.
.

And... that's it. Running freebsd-update will use the ServerName domain which is your reverse nginx proxy. Note the comment about using a "nearby" server is not quite true. FreeBSD update mirrors are frequently slow and running such a reverse proxy cache significantly speeds things up.

Caveats

This is a simple cache. That means it doesn't consider the files as a whole repository, which in turn means updates to your cache are not atomic. It'd be advised to nuke your cache before your update run, as its point is only to retain the files in a local cache for some short period of time required for all your machines to be updated.

CategoryHowTo