FreeBSD_Update [FreeBSD WIKI]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== FreeBSD Update (freebsd-update) =====

%%FreeBSD%% Update is a binary update system for %%FreeBSD%% [[Glossary#Base|base]]. It consists of a server and client component.

  * [[https://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html|FreeBSD Handbook: FreeBSD Update]]
  * [[https://man.freebsd.org/cgi/man.cgi?query=freebsd-update&sektion=8&manpath=freebsd-release|freebsd-update(8) Manual Page]]

===== How to check for latest available version =====

<code>
$ 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
</code>

Output looks like:

<code>
freebsd-update|amd64|12.0-RELEASE|10|cae42a89f90be555b530a759cd400925bce03ed73ee78e665bef3fe5293e872f|1576022400
</code>

"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:

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

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**

<code>

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;
    }
}

</code>

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

<code>
# $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

.
.
.
</code>

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.

----

{{tag>HowTo}}