getting the running patch level

Thomas freebsdlists at
Fri Aug 24 13:02:22 UTC 2012

On 8/19/12 4:46 PM, Paul Schenkeveld wrote:
> On Thu, Aug 09, 2012 at 11:44:02AM +0200, Roberto wrote:
> Having read all responses so far I think a summary of the issue at hand
> is:
>   - Uname only reports on the kernel version, currently we do not store
>     nor report the userland version.
>   - People would love to know what version of FreeBSD, both kernel and
>     userland, is currently installed/running.
>   - Userland can either be upgraded using make {build,install}world or
>     by freebsd-update, neither logs the version to which userland was
>     updated.
>   - Reporting the userland version is not trivial as not necessarily all
>     parts of userland are of the same version, especially after doing
>     an buildworld/instrallworld with a changed src.conf or make.conf.
>   - We currently reflect the last booted kernel version in /etc/motd.
> My suggestion would be:
>   - Teach both installworld and freebsd-update to maintain manifest
>     files of what is installed and log that update, place all manifests
>     somewhere under /var/db and the update log in /var/log.
>   - If the above log message is well defined and includes the method
>     by which the update was done, it can be parsed by /etc/rc.d/motd
>     and we could extend the information in /etc/motd to also include
>     information about userland.  Something like:
>       <tool> <timestamp> <who> <current-version>
>       portupgrade 2012-08-19T16:26:41 paul 8.3-RELEASE-p4
>       installworld 2012-08-19T16:31:36 paul 8-STABLE-r231558
>   - Having manifests of what's installed, one could check if all files
>     are stil the right version, if older manifests are not discarded
>     when performing an update this could also detect files that were
>     not updated for whatever reason or that were reverted, i.e. by
>     restoring some backup.  E.g.:
>       Current userland version: 8.3-RELEASE-p4
>       /usr/sbin/named is at 8.3-RELEASE-p2
>       /usr/bin/openssl is at 8.3-RELEASE
>   - Such a time-consuming check could be run from periodic (weekly or
>     monthly perhapd) and be a valuable tool to warn sysadmins of files
>     not being what they should be.
>   - Adding, in the case of freebsd-update, a signature to the manifest
>     files that can be checked against the signature in the freebsd-update
>     master repository could turn this tool into something of a integrity
>     checking tool.

Sounds good if you have a just a few systems. In a large environment,
snmp is quite common to collect release information.

AFAIK snmp uses kern.version and kern.osrelease for this.This sysctls
are read only. Any ideas how this issue can be fixed for
snmp in a easy way?


More information about the freebsd-security mailing list