Following -current and using snapshots

OpenBSD Following -current and using snapshots [FAQ Index]

Active OpenBSD development is known as the -current branch. These sources are frequently compiled into releases known as snapshots.

Aggressive changes are sometimes pushed in this branch, and complications can arise when building the latest code or upgrading from a previous point in time. Some of the steps for getting over these hurdles are explained on this page. Make sure you've read and understand how to build the system from source before using -current and the instructions below.

In general, it's far easier to use snapshots, as developers will have gone through much of the trouble for you already.

You should always use a snapshot as the starting point for running -current. This process typically consists of running sysupgrade(8) with the -s flag. Alternatively, download (and verify) the appropriate bsd.rd file from the /snapshots/ directory of your preferred mirror, boot from it, and choose (U)pgrade at the prompt. Any installed packages should then be upgraded after booting into the new system.

Upgrading to -current by compiling your own source code is discouraged for everyone except for experts, as difficult build-time crossing-points can occur often, and no assistance will be provided. In case of failure, use a snapshot to recover.

Most of these changes will have to be performed as root.

2020/11/07 - iked.conf "to dynamic"

New keywords have been introduced to iked.conf(5) to simplify the configuration when using "config address". Previously, when either "to 0.0.0.0" or "to 0.0.0.0/0" were used, they would be replaced with the peer's assigned address when creating flows. "to dynamic" has been introduced to make the configuration syntax clearer.

"to 0.0.0.0" works as before but can be updated to the new syntax if wanted.

"to 0.0.0.0/0" will now be treated literally; if you want the old behaviour you must change to "to dynamic".

2020/12/16 - pf port range validation

pf(4) and pfctl(8) are now stricter about validating rules which use port ranges.

The following show incorrect rules that were previously accepted: "port 2004:2000", "port 2004 >< 2000", "port 2004 <> 2000" (range should be low-high), and "port 2000 >< 2000" (range should not be a single port).

If you use ranges and don't have console access, check them before upgrading.

2020/12/29 - new sysctl setting to control video recording

Similar to how audio recording is handled, recording has been disabled by default in video(4). It may be reenabled like this:

    # sysctl kern.video.record=1 # enable at runtime
    # echo kern.video.record=1 >> /etc/sysctl.conf # set at boot

2021/01/16 - sysctl forwarding for pf af-to

Even if forwarding was not configured, pf(4) allowed to forward packets with af-to. To continue using NAT64 you have to set these sysctl:

    # sysctl net.inet.ip.forwarding=1
    # sysctl net.inet6.ip6.forwarding=1

2021/01/18 - www/rt config directory change

The update to 5.0.0 moves the default config directory from /etc/rt3 to /etc/rt. Make sure to move all the modified configuration files to the new path.

2021/01/22 - snmpd traphandler changes

Cleanup in snmpd(8)'s traphandler code lead to the following changes:

Defining a trap handle now requires explicit enabling of notify functionality on the listen socket, where it previously would enable a listen socket on every UDP listen on statement. For identical behaviour the UDP listen on statements need to be duplicated with an notify flag appended.
```
listen on 127.0.0.1
```
would become
```
listen on 127.0.0.1
listen on 127.0.0.1 notify
```
Incoming trap packets are now checked against trap community, where it would previously ignore the community.
traphandler_v1translate now fully complies to RFC3584 section 3.1, where it previously only implemented bullet (2) on generic-trap >= 6. People using SNMPv1 traps are encouraged to verify their trap handle scripts before updating. Handlers for generic-trap < 6 need to modify their trap handle scripts and potentially add trap handle statements in accordance with RFC3584 section 3.1 bullet (3).
Running snmpd(8) without -N now prints iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0 (first varbind) in accordance with its internal MIB definitions (iso.org.dod.internet.mgmt.mib_2.system.sysUpTime.0).
Running snmpd(8) with -N now prints iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0 (first varbind) numerically (.1.3.6.1.2.1.1.3.0).
Running snmpd(8) with -N now prints iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap.snmpTrapOID.0 (second varbind) numerically (1.3.6.1.6.3.1.1.4.1.0).

2021/02/01 - pf routing syntax changes

Syntax for PF's routing options (route-to, reply-to, dup-to) has changed. If you do not have console access and use these features, review /etc/pf.conf before updating; the previous syntax will be rejected by pfctl(8).

These options previously accepted an IP address and network interface, for example:

    # address is directly reachable via the interfaces (showing both accepted formats)
    pass out proto tcp to port {80 443} route-to 192.0.2.1@ix0
    pass out proto udp to port 53 dup-to (em2 192.168.2.99)

    # using placeholder address to signify the remote address on a point-to-point link
    pass in on pppoe1 reply-to 0.0.0.1@pppoe1

They now take only an IP address, and perform a route lookup to determine the interface. The above examples can now be written like so:

    # address is directly reachable via the interfaces
    pass out proto tcp to port {80 443} route-to 192.0.2.1
    pass out proto udp to port 53 dup-to 192.168.2.99

    # using :peer to use the remote address on a point-to-point link
    # using (...) to track changes dynamically
    pass in on pppoe1 reply-to (pppoe1:peer)

Alternatively, for some configurations using these features, it may be simpler to use multiple route tables instead (using ifconfig's rdomain and pf.conf's rtable features).

$OpenBSD: current.html,v 1.1062 2021/02/01 13:49:52 sthen Exp $