# How to determine if freebsd-version is up to date with -RELEASE?



## Mike Selner (Mar 6, 2016)

Hi,

I'm running FreeBSD 9.3-RELEASE and FreeBSD 10.2-RELEASE systems. I'd like an automated way to determine if there is an update available.

Is there a clean way to determine if the current system version as reported by `freebsd-version` (-u, -k) is up to date with the security patches in -RELEASE? I would like this to be included in a nightly report similar to "`# pkg upgrade -n`"

Currently I find out when there's a new patch level when I get a security advisory, or I can run freebsd-update fetch.   I'd rather not run "`# freebsd-update fetch`" unattended.

Also it would be useful if it indicated if the kernel level will be updated so I can schedule a reboot.

TIA


----------



## ANOKNUSA (Mar 6, 2016)

freebsd-version(1) is actually just a demo program (see/usr/share/exampnles/FreeBSD_version/README). If you want to know if updates are available, regularly check the FreeBSD homepage (the "Security Advisories" and "Errata" sections) or subscribe to freebsd-announce@. Releases only get updated for bug or security fixes, so every available update is announced in those places.

You could also just periodically run `freebsd-update fetch`. If updates are available, it will fetch them. It will only install them when you tell it to. Cron jobs in /etc/crontab are included in regular mail reports.



Mike Selner said:


> Also it would be useful if it indicated if the kernel level will be updated so I can schedule a reboot.



freebsd-update(8) does this. From my experience, kernel updates to -RELEASE are pretty rare.


----------



## Mike Selner (Mar 6, 2016)

Sorry if this was not clear. I'm referring to /bin/freebsd-version which is in base since 10.0.

What I'd like to do is have `periodic daily` or `periodic security` include a report indicating whether or not updates are available to the kernel and userland.

I currently do the manual steps and I would like a way to include this information in an AUTOMATED way that does not alter the system in any significant way.

Let's say the current system shows:

```
# freebsd-version -k -u
10.2-RELEASE-p8
10.2-RELEASE-p10
```

Desired result similar to `pkg version -v`:
(`freebsd-version -v` could mean "version"; `freebsd-version -a` could mean "audit")

```
# freebsd-version -k -u -v
10.2-RELEASE-p8  <  needs updating (10.2-RELEASE-p9 is latest available 10.2-RELEASE kernel version)
10.2-RELEASE-p10 <  needs updating (10.2-RELEASE-p11 is latest available 10.2-RELEASE userland version)
```
and when up to date:

```
# freebsd-version -k -u -v
10.2-RELEASE-p9  =  up-to-date  (10.2-RELEASE-p9 is latest available 10.2-RELEASE kernel version)
10.2-RELEASE-p11 =  up-to-date (10.2-RELEASE-p11 is latest available 10.2-RELEASE userland version)
```
Additionally if `periodic security` could include a list of unapplied security patches that would be very helpful. For example something like this (similar to `pkg audit`):

```
# freebsd-version -a
Kernel 10.2-RELEASE-p8 is vulnerable:
Advisory: FreeBSD-SA-16:05.tcp TCP MD5 signature denial of service
CVE:  CVE-2016-1882
Corrected: releng/10.2, 10.2-RELEASE-p9

Advisory: FreeBSD-SA-16:09.ntp
Multiple vulnerabilities of ntp
CVE: CVE-2015-7973, CVE-2015-7974, CVE-2015-7975, CVE-2015-7976
Corrected: releng/10.2, 10.2-RELEASE-p11
```
Does something like this currently exist?


----------



## jef (Mar 9, 2017)

I would agree that a "clean" way to test if there is a new version is available would be very useful. It could also reduce traffic on the update servers.

Something as simple as a GET with a RELEASE parameter that returns the latest patch level would suffice for me.

In particular, as I'm running a custom kernel (built off the as-delivered sources, but with a different configuration), there are _always _changes reported, even if they don't impact me.

Just today:

```
jeff@js:~$ freebsd-version -ku
11.0-RELEASE-p8
11.0-RELEASE-p8

jeff@js:~$ sudo freebsd-update fetch
Password:
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 11.0-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

The following files will be updated as part of updating to 11.0-RELEASE-p8:
/boot/kernel/cam.ko
/boot/kernel/hv_storvsc.ko
/boot/kernel/kernel
/usr/lib/debug/boot/kernel/cam.ko.debug
/usr/lib/debug/boot/kernel/hv_storvsc.ko.debug
/usr/lib/debug/boot/kernel/kernel.debug
/usr/share/man/mandoc.db
/usr/share/openssl/man/mandoc.db
```


----------



## ANOKNUSA (Mar 11, 2017)

jef said:


> In particular, as I'm running a custom kernel (built off the as-delivered sources, but with a different configuration), there are _always _changes reported, even if they don't impact me.



See *Components* in freebsd-update.conf(5)



jef said:


> It could also reduce traffic on the update servers.



How is a program pinging the servers tens of thousands of times a day supposed to reduce traffic on those servers?


----------



## jef (Mar 28, 2017)

On the first point, having a GENERIC kernel always available, is a critical asset. I'd rather not have to build _both _kernels locally. Especially if there is some kind of corruption, having a known-good kernel built and validated off the machine in question is important.

On the second point, those pings are going to occur no matter what. Returning a couple dozen bytes about the most-recent version is significantly less bandwidth than the several kB of data is presently returned.


----------



## ShelLuser (Mar 28, 2017)

I'm a little confused, why run RELEASE in the first place? I mean, that's basically a development version, as such not necessarily stable and basically an update for them can happen every day (referring to code submits).

I think it might be easier on you to use a RELENG version and then utilizing freebsd-update(8) to check for new updates. For example by using `# freebsd-update cron` which will check for updates and send you an e-mail if one is found.


----------



## jef (Mar 28, 2017)

ShelLuser said:


> I'm a little confused, why run RELEASE in the first place? I mean, that's basically a development version, as such not necessarily stable and basically an update for them can happen every day (referring to code submits).


RELEASE _is _the production version, drawn from the releng _branch. _It is STABLE and CURRENT that are development branches.

See further https://www.freebsd.org/releases/ and https://www.freebsd.org/security/security.html#sup for example


----------



## ANOKNUSA (Mar 28, 2017)

jef said:


> On the first point, having a GENERIC kernel always available, is a critical asset.



Alright, then see the *IgnorePaths* entry instead. You can leave the GENERIC kernel in /boot/kernel; install your custom kernel to /boot/kernel.kernelname with the command `make installkernel KODIR=/boot/kernel.kernelname`; put the line `kernel=kernel.kernelname` in /boot/loader.conf; and add /boot/kernel.kernelname to the "IgnorePaths" line in /etc/freebsd-update.conf. Your system will boot from your custom kernel by default, and freebsd-update(8) will update your source tree and GENERIC kernel while ignoring your custom kernel entirely.



jef said:


> On the second point, those pings are going to occur no matter what. Returning a couple dozen bytes about the most-recent version is significantly less bandwidth than the several kB of data is presently returned.



That storm of pings only occurs if the majority of users decide they want to run a program to check for updates again and again and again and again, instead of just running it to install an update once every few weeks when they get an email announcing the update. The latest patch level for 11.0 is -p8, released on February 23. There haven't been any updates in over a month since that release. I know this because I haven't gotten an email notifying me of the updates in that time. -p7 was released on January 11, some 7 weeks before that. I'm not gonna run freebsd-update(8) over and over checking for another update. It seems to me that the most elegant possible solution to the "problem" already exists.


----------



## jef (Mar 28, 2017)

ANOKNUSA said:


> Alright, then see the *IgnorePaths* entry instead. You can leave the GENERIC kernel in /boot/kernel; install your custom kernel to /boot/kernel.kernelname with the command `make installkernel KODIR=/boot/kernel.kernelname`; put the line `kernel=kernel.kernelname` in /boot/loader.conf; and add /boot/kernel.kernelname to the "IgnorePaths" line in /etc/freebsd-update.conf. Your system will boot from your custom kernel by default, and freebsd-update(8) will update your source tree and GENERIC kernel while ignoring your custom kernel entirely.



Very reasonable approach, thanks!


----------



## IPTRACE (Mar 29, 2017)

I've added the alias *newver* to my .cshrc file.
You have to install lynx browser.


```
alias newver    'lynx -dump http://svn.freebsd.org/base/releng/11.0/sys/conf/newvers.sh | grep -E "TYPE|REVISION|BRANCH" | head -3'
```
Then when I run that command I have the following output.

`admin@test:~ % newver
TYPE="FreeBSD"
REVISION="11.0"
BRANCH="RELEASE-p8"
admin@test:~ %`

I set *newver* in my startup login script (file .login), so everytime when I login exp. via SSH I see if new patches are available.


----------



## tobik@ (Mar 29, 2017)

IPTRACE said:


> I've added the alias *newver* to my .cshrc file.
> You have to install lynx browser.


Why not use fetch(1)?
`fetch -qo - http://svn.freebsd.org/base/releng/11.0/sys/conf/newvers.sh | grep -E "TYPE|REVISION|BRANCH" | head -3`


----------



## IPTRACE (Mar 29, 2017)

tobik@ said:


> Why not use fetch(1)?
> `fetch -qo - http://svn.freebsd.org/base/releng/11.0/sys/conf/newvers.sh | grep -E "TYPE|REVISION|BRANCH" | head -3`


Thanks, I'll try it.


----------



## Max Khon (Oct 21, 2019)

You can use this: https://github.com/mkhon/zabbix-freebsd-release


----------

