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

M

Mike Selner

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
 
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.
Click to expand...

freebsd-update(8) does this. From my experience, kernel updates to -RELEASE are pretty rare.
 
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:
Code: 
# 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")
Code: 
# 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:
Code: 
# 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):
Code: 
# 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?
 
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:
Code: 
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
 
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.
 
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 said:
On the first point, having a GENERIC kernel always available, is a critical asset.
Click to expand...

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.
Click to expand...

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.
 
  • Thanks
Reactions: jef
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.
Click to expand...

Very reasonable approach, thanks!
 
I've added the alias newver to my .cshrc file.
You have to install lynx browser.

Code: 
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.
 
You must log in or register to reply here.
Back
Top